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ABSTRACT 


All  sectors  of  society  are  confronted  with  what  has  been 
termed  the ^software  crisis.  <^As  the  world’s  largest  single 
buyer  cf  software,  the  Department  of  Defense  has  undertaken 
major  software  initiatives  to  ameliorate  software-rela ted 
problems  associated  with  major  computer  systems  acguisition. 
This  thesis  provides  an  overview  of  commom  problems  in  both 
embedded  and  administrative  software  development  and  acgui¬ 
sition.  It  defines  guality  software  in  terms  of  its  charac¬ 
teristics,  and  provides  the  project  manager/acguisition 
agency  with  a  set  of  accepted  controls  to  assure  that 
guality  is  built  in  to  software  for  improved  maintain¬ 
ability.  The  difficulties  and  limitations  of  providing  accu¬ 
rate  estimates  in  software  development  are  discussed  in 
terms  of  software  metrics.  A  number  of  DoD  current  and 
future  standardization  efforts  are  discussed,  including  the 
Army’s  development  of  a  Military  Computer  Family  (MCF) ,  Ada, 
and  the  STARS  initiative.  Key***  rf  f  -//arar, 
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I.  INTRODUCTION 


A.  BACKGROUND 


"And  a  good  south  wind  sprung  up  behind; 

The  Albatross  did  fellow. 

And  every  day,  for  food  or  play. 

Cane  tc  the  mariner's  hollo! 

God  save  thee.  ancient  Mariner! 

From  the  fiends  that  plague  thee  thus! — 

Why  lock'st  thou  so?-- With  my  crpss-bow 
I  shot  the  Albatross."  [The  Ancient  Mariner,  pt.  i] 


The  albatross  around  today's  progr&n  manager  neck  is  often 
the  software  subcomponent  of  major  system  acquisitions.  Cost 
overruns,  schedule  slippages,  and  loss  of  program  control 
have  been  the  penance  for  those  project  managers  who  have 
failed  to  provide  for  software  with  the  same  intensive  and 
continuing  management  typically  rendered  its  hardware 
counterpart. 

Software  is  an  intangible  product  that  defies  descrip¬ 
tion  in  an  engineering  sense.  Only  a  few  software  products 
have  ever  started  off  with  clear,  unambiguous,  and  defini¬ 
tive  requirement  specification.  Schedules  and  costs  are 
often  dictated  by  the  system  acquisition  milestones  and 
reviews,  and  not  necessarily  associated  with  the  phased 
software  development  methodologies  advocated  by  what  has 
been  termed  "software  engineering*".  Many  of  the  specific 
problems  that  surround  software  development  and  acquisition 
will  be  discussed  in  detail  in  the  next  chapter. 


..x?ke,key  objectives  of,  software  engineering  are  (1)  ,  _ 
well-defined  methodology,  that  addresses  all  phases  of  the 


of  soft\ 

„  .  _ Logy  that  at _ , _  _ . _  _ _ 

software  life  cycle,  (2)  an  established  set  of  software 
components  to  document  ana  show  traceability  from  one  devel¬ 
opment  step  to  the  next,  and  (3)  a  set  of  predictable  mile¬ 
stones  that  can  be  reviewed  as  needed  [Ref.  1  :  p  15]. 
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in  the  majority  cf  guidance  and  managerial  principles 
available  to  assist  the  program  manager  are  directed  at  the 
hardware  end.  Software  is  the  "new  kid  on  the  block.”  It  is 
that  part  of  the  system  that  is  seldom  understood  and  often 
mismanaged  during  system  acquisitions.  Computer  hardware,  on 
the  other  hand,  has  undergone  remarkable  improvements  in 
function,  size,  performance,  and  relative  cost.  Several 
hardware  generations  liave  emerged  in  the  course  of  a  single 
human  generation.  Yet,  software  has  experienced  more  notice¬ 
able  growing  pain.  The  gap  between  hardware —  and  software 
technology  widens. 

B.  THE  COST  OP  SOFTWAHE  III  DOD 

There  are  two  general  classifications  of  software  within 
DoD.  The  first  of  these  is  that  of  the  more-traditional, 
administrative  type  cf  software  used  in  business  applica¬ 
tions.  This  type  of  software  is  typically  supported  by 
commercially  available  computer  that  can  support  a  variety 
of  applications,  i.e. ,  Automatic  Data  Processing  (ADP; 
systems.  The  second  classification  is  embedded  software. 
Embedded  software  is  normally  designed  to  operate  as  an 
integral  part  of  ncn-ADP  systems,  such  as  DoD  tactical 
systems.  The  most  significant  difference  between  these  two 
classifications  of  software  rest  not  in  the  development  and 
maintenance  practices,  but  rather  in  the  frame  work  in  which 
they  are  each  procured. 

The  procurement  authority  for  Automatic  Data  Processing 
Equipment  (ADPE)  and  its  supporting  software  and  services  is 
vested  in  the  General  Services  Administration  (GSA)  ,  as 
directed  by  Public  law  89-306,  40  OSC  759,  the  "Brooks 
Bill.”  Within  DoD,  ADPE  is  under  the  purview  of  the 
Assistant  Secretary  of  Defense  (Comptroller).  Weapon  system 
software  is  under  the  cognizance  of  the  Office  of  the 
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Undersecretary  of  Defense  (Research  and  Engineering).2 
Although  there  is  a  distinct  dichotomy  of  cognizant  organi- 
rational  structures  regulating  the  acquisition  of  ADP  and 
non-ADP  software,  the  managerial  and  software  engineering 
principles  which  govern  each  step  of  the  software  life  cycle 
are,  in  fact,  quite  similar.  Therefore,  the  common  set  of 
tools,  methods,  and  methodologies  advocated  in  this  thesis 
apply  to  both  ADP  and  non-ADP  software. 

In  writing  this  thesis,  it  was  noted  that  the  majority 
of  available  DoD  guidance  for  the  control  and  acquisition  of 
software  projects  was  in  support  of  tactical  systems,  with 
the  vast  majority  being  authored  for  the  United  States  Air 
Force.  This  is  not  suprising  since  it  has  been  estimated 
[Kef..  2  s  p.  7}  that  of  the  $12  billion  that  DoD  will  spend 
for  software  in  1985,  over  $10  billion  will  be  for  embedded 
software,  with  the  U.  S.  Air  Force  accounting  for  approxi¬ 
mately  half  of  the  expenditures. 

Not  only  does  embedded  software  represent  the  largest 
component  of  total  software  costs  in  DoD4  it  is  also  plagued 
to  a  proportional  degree  with  many  of  of  the  software- 
related  problems,  which  M.N.  Lehman  so  aptly  describes  as 

"a  motley  collection  of  relatively  isolated  methodolo¬ 
gies  and  techniques,  associated  through  an  experience- 
based.  but  otherwise  arbitrary  sequence  of 
much-discussed  process  phases".  [Ref.  3  :  p.  3] 

At  this  point,  it  is  important  to  recognize  some  of  the 
some  of  tho  program  characteristics  that  add  to  the  complex¬ 
ities  of  DoD’s  embedded  software.  These  include:  [Bef.  4  : 
p.  77] 


•Due  in  large  part  to  the  provisions  set  forth  in  the 
subsequent  Warner  Aamenment.  the  policies  and  procedures  set 
forth  in  the  Brooks  Bill  does  not  extend  to  the  tactical 
software  used  in  DoD  weapons  systems. 
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—  |rggram  size— often  in  excess  of  a  million  lines  of 

—  real-time  operating  requirements  requiring  response 
time  in  milliseccnds. 


programs  must  be  flexible  to  accommodate^  changes  in 
system  evolution  over  an  expected  useful-life  often 
in  excess  of  twenty  years. 


—  guaranteed  reliability  due  to  the  tight  (and  many 
times  life-  dependent)  coupling  between  the  system 
ana  its  user  or  the  population  that  the  system  is 
designed  to  protect. 

—  programs  are  part  of  the  universe  which  they  model 
and  control. 


As  compared  to  other  software  applications,  such  as  ADP 
or  administrative  computing,  DoD  mission-critical  software 
is  more  complex,  less  understood,  more  unstable,  and  must 
operate  in  extreme  environmental  conditions.  Yet  it  is 
essential  that  DoD  software  be  reliable,  adaptable,  and 
affordable.  To  achieve  these  objectives,  many  problems,  of 
both  a  technical  and  managerial  nature,  must  be  overcome. 
Symptoms  of  these  problems  include  slippages  in  weapon 
delivery  schedules,  system  failures,  overbudget  programs, 
and  inflexible  systems  will  be  discussed  at  further  lengths 
in  Chapter  II. 

DoD  is  recognized  as  the  world’s  largest  buyer  of  soft¬ 
ware.  Based  on  various  estimates  in  recent  literature,  it  is 
calculated  that  DoD  will  spend  approximately  $12  billion  for 
software  in  1985  [Bef.  2  :  p.  5]*  Table  1  illustrates  the 
percentage  of  total  computing  system  costs  of  hardware  as 
compared  to  software  for  all  of  DoD  computing  systems. 
Software  cost  reflect  all  aspects  of  the  software  life 
cycle,  including:  design,  development,  testing,  operations, 
and  maintenance.  The  ratio  of  hardware  to  software  has 
reversed  itself  frco  4:1  to  that  what  is  expected  to 
approach  1:9  next  year.  [Bef.  2  :  pp.  5-6]. 

The  high  cost  of  acquiring  software  has  naturally 
caused  concern  in  bcth  DoD  and  the  Congress.  Literature 


TABLE  1 

Cost  Tran (3s;  Hardware  versus  Software 

(percentage  of  total  cost) 

1955_  1970_  _  1979  (Estimate)^  __ 

Ililsiii  ?i  jj 

- - - 


abounds  with  studies  and  recommendations  related  to  software 
development  in  DoD.  There  Is  not  a  shortage  of  sage  advise. 
The  need  for  improved  managerial  controls  and  software 
development  practices  has  been  recognized. 

C.  PUB POSE  AND  APPBOACH 

A  major  goal  of  this  thesis  is  to  present  a  consolidated 
review  of*  major  DoD  efforts  aimed  at  reducing  software** 
related  problems.  Both  management  and  technical  issues  will 
be  addressed.  This  thesis  makes  no  pretense  that  it  provides 
the  program  manager  with  all  of  the  technical  background  and 
controls  needed  to  assure  the  timely  delivery  of  quality 
software  within  budeget.  Rather,  it  focuses  on  key  and 
"high  payoff"  issues  involved  in  managing  the  acquisition 
and  development  of  software.  This  thesis  also  addresses 
several  DoD  initiatives  which  promise  to  significantly  alter 
the  framework  in  which  software  is  developed  and  maintained. 

Chapter  II  identifies  many  common  problems  associated 
with  contracting  for  general  computer  software  by  Federal 
agencies.  It  also  identifies  major  contributing  factors  to 
DcD  weapon  system  software  problems.  A  common  denominator  in 
the  formulation  of  the  many  software  problems  is  the  lack  of 
estimating  expertise  by  which  program  measurements  can  be 


defined.  Chapter  III  discusses  software  metrics  for  defining 
quantifiable  measurements. 

The  delivery  of  good  software  is  an  implicit ,  hut  most 
elusive,  goal  in  software  acquisition.  Chapter  IV  defines 
"good  software"  through  a  set  of  quality  software  character** 
isticsu  It  also  provides  a  series  of  controls  to  be  utilized 
in  the  isplementation  of  a  quality  assurance  program.  Major 
dividends  from  quality  software  are  realized  during  the 
post* development  phase  of  software,  the  maintenance  phase. 
Chapter  V  analyzes  the  tangible  and  intangible  costs  of 
software  maintenance,  and  addresses  a  number  of  software 
engineering  principles  through  which  the  costs  of  mainte¬ 
nance  can  be  greatly  reduced. 

Chapter  VI  and  VII  review  a  number  of  software  and 
computer-  technology  standardization  initiatives  to  under¬ 
taken  within  SoO.  Perhaps  the  most  significant  of  these 
initiatives  is  the  STABS  (Software  Technology  for  Adaptable, 
Sellable  Systems)  program. 

Finally,  Chapter  VII  provides  this  thesis’  conclusions 
and  recommendations. 
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ii.  Jfif  SfiifiiS 


"The  problem  of  the  1970* s  was  to  reduce  the  cost  of  the 

Slectronic  functions  needed  to  store  and  process 

a  t  a  • .  • « 


"The  problem  of  the  1980's  _ 

reduce  the  cost  of  electron, 

E  educing  the  cost 
ulla  a  product, 
shift  from  the  com 
concentration  of  sy 


different.  Now  .  we  must 

'  at  is 


is  different 

or  electronic  solutions;  tnac  is, 
you .incur,  in  using  our  devices  to 
Solving  this  problem  will  require  a 
ponent  integration  of  the  197g's  to 
stem  level  integration  in  the  1980 's. 


.ntegration 


to 

a 

o 


"We  can  now  that  about  putting  power  of 
on  a  single  chip.  This  buys  you  nothing 
however,  unless.  you  can  use  that  power.  Hardy 
computing  potential;  it  must  be  harnessed  and  ari 
software  to  be  useful."  £Bef.  1  :  p. 22] 


a  mainframe  CPU 
as  a  customer, 
are  is 
ven  by 


The  preceding  statement  was  made  by  the  president  of  one 
of  the  largest  manufacturers  of  computer  hardware.  It 
succinctly  summarizes  the  shift  in  technological  emphasis 
from  hardware  to  software. 


A.  FROB1EHS  IN  SOFT VIBE  ACQUISITION 

To  the  casual  observer,  the  successful  management  of  a 
software  development  project  may  seem  a  simple  process.  All 
that  is  needed  are  (1)  well-defined  requirements,  (2)  real¬ 
istic  cost  and  schedule  estimates,  and  (3)  the  right  quan¬ 
tity  of  personnel  and  hardware  at  the  right  time.  In 
actuality,  each  of  these  elements  seldom,  if  ever,  happens 
by  themselves,  much  less  together. 

The  management  of  software  development  projects  have 
historically  been  plagued  by  a  myriad  of  problems,  both  in 
the  private  and  government  sectors. 

1.  £  GAO  £e£2£t 

Recently  GAC  reported  to  Congress  [Eef.  5  :  pp.  1  - 
84]  a  number  of  problems  that  Federal  agencies  have 


•encountered  in  contracting  for  computer  software  as  an 
alternative  to  in-house  development.  Means  for  improving 
these  deficiencies  were  also  recommended. 

a.  Scope  of  the  GAO  Report 

GAO  sent  guestionnaires  to  163  software 
contracting  firms  and  113  Federal  project  offices  that  had 
experience  with  software  development  projects.  The  purpose 
of  the  guestionnaires  was  to  attempt  to  identify  common 
problems  in  software  development  contractual  process  and 
what,  through  hindsight,  might  have  been  done  to  prevent  or 
improve  development  efforts. 

GAO  examined  nine  cases  of  software  development 
in  detail,  some  of  which  had  attracted  GAO  attention  because 
they  were  known  failures.  Only  one  of  these  nine  cases 
yielded  a  software  product  that  could  be  used  as  delivered. 

The  actual  combined  total  development  cost  and 
time  for  the  nine  cases  almost  doubled  the  estimates  of  $3.7 
million  and  10.8  years. 

t.  Common  Causes  of  Software  Contracting 

The  nine  cases  that  were  studied  in  detail 
illustrated  many  of  the  same  causes  of  difficulties  that 
respondents  to  the  GAC's  guestionnaires  had  identified.  The 
most  significant  of  these  findings  will  now  be  described: 

—  Federal  agencies  contract  for  software  development 
with  little  specific  guidance. 

Guidelines  for  software  development  promulgated 
by  central  agencies  are  primarily  aimed  at  the  technical 
aspects  of  software  development.  Very  little  guidance  is 
provided  in  support  of  the  contractual  process. 

Basic  responsibilities  of  the  central  agencies 
are  set  forth  in  the  Brooks  Act,  Public  Law  89-306.  The 


Office  of  Management  and  Budget  (OMB)  is  prescribed  general 
oversight  of  Automatic  Data  Processing  (ADP)  activities. 
Much  of  this  responsibility  has  been  delegated  to  the 
General  Services  Administration  (GSA)  and  to  the  National 
Bureau  of  Standards  (NBS).  GSA  is  delegated  the  responsi— 
bility  for  ensuring  cost  effectiveness  in  the  selection, 
acquisition,  and  utilization  of  ADP  resources.  GSA's 
guidance  for  the  management  of  ADP  resources  is  contained  in 
subpart  101-32  of  the  Federal  Property  Management 
Begulations. 3  Policies  addressing  the  procurement  of  and 
contracting  for  commercially  available  software  is  provided 
in  Federal  Procurement  Hegulation  1-4.11.  GAO’s  review  of 
both  of  these  documents  revealed  that  there  is  very  little 
actual  guidance  directed  at  the  specific  contractual  manage¬ 
ment  for  engaging  in  custom  software  development. 

Although  NBS  is  tasked  with  developing  technical 
standards  and  guidelines,  OMB  has  indicated  that  NBS  is  also 
responsible  for  investigating  and  assisting  in  software 
system  developments.  Although  NBS  representatives  advised 
GAO  that  their  responsibilities  involved  managerial  and 
contractual  activities  for  system  development,  NBS'  emphasis 
has  been,  and  will  continue  to  be,  on  the  technical  aspects 
of  system  development,  such  as  the  standardization  of 
government-used  Higher  Order  Languages. 

5f®®cieSu°Ye£esti®?te  the  stage  of  their  own  prelimi¬ 
nary  work  before  they  contract.  * 

GAO  found  two  primary  reasons  why  agencies 
contract  out  for  software  development  instead  of  doing  it 
in-house.  The  first  is  that  many  of  the  agencies  lack  suffi¬ 
cient  quantities  of,  or  properly  skilled,  personnel  to  do 


the  work.  Secondly,  the  software  is  often  needed  sooner  than 
it  can  be  produced  in-house.  Often  the  initial  steps  of 
software  development,  such  as  requirement  analysis,  are 
started  in-house  prior  to  contracting  out  for  the  continued 
development  of  required  software.  Two  common  problems  have 
been  observed  in  this  context.  First,  the  agency  may  overes¬ 
timate  the  amount  of  work  already  achieved  in-house 
secondly,  the  agency’s  preliminary  work  that  is  turned  over* 
to  the  contractor  may  be  inadequate  requiring  that  it  be 
done  again  by  the  contractor. 

Overestimating  the  stage  of  software  development 
before  releasing  it  to  a  contractor  is  likely  to  result  in 
additional  costs  to  the  extent  that  any  cost  benefits  that 
might  have  been  gained  from  the  development  project  are 
forfeited.  It  is  critical  that  precise  methods  for  measuring 
preliminary  in-house  work  be  used  in  order  to  achieve  real¬ 
istic  cost  and  time  estimates.  An  accurate  identification  of 
the  stage  of  system  development  is  vital  in  order  to  prop¬ 
erly  determine  the  type  of  contract  to  be  utilized.  If,  for 
example,  the  agency  has  completed  all  the  preliminary  devel¬ 
opment  stages  required  prior  to  the  commencement  of  coding, 
then  a  firm-fixed  price  contract  for  the  coding  effort  might 
be  the  most  suitable.  If,  on  the  other  hand,  a  systems 
detailed  design  has  not  been  completed  by  the  agency  prior 
to  entering  into  a  contractual  agreement,  then  a  phased, 
cost-plus-  fixed-fee  type  contract  would  likely  be  more 
suitable  since  the  exact  scope  of  future  efforts  is  not  yet 
known. 

If  agency  work  that  is  passed  on  to  the 
contractor  is  later  found  to  be  inadequate,  or  less  than 
originally  estimated,  much  of  the  work  may  have  to  be  redone 
by  the  contractor.  In  doing  so,  there  often  is  a  tendency  to 
attempt  to  save  as  much  of  the  original  work  as  possible  in 
order  to  remain  within  the  cost  and  time  ceiling  mandated  by 
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the  contract.  This  is  likely  to  compromise  the  design  of  the 
new  system,  resulting  in  a  less  efficient  system  that 
mandates  higher  operating  and  maintenance  cost  for  the 
remainder  of  its  life  cycle. 

—  Contracts  fail  to  stipulate  what  constitutes  satis¬ 
factory  performance. 

Failing  to  stipulate  what  constitutes  satisfac¬ 
tory  performance  by  the  contractor  makes  it  difficult/  if 
not  impossible/  to  claim  poor  contact  performance. 
Furthermore,  it  reduces  the  probability  of  a  satisfactory 
end-product.  Many  disputes  over  contractor  performance  could 
be  avoided  if  adequate  system  specifications  and  testing 
criteria  are  identified  in  the  contract. 

Other  general  requirements  and  constaints  that 
can  usually  be  identified  at  the  start  of  a  software  project 
criteria  for  software  expandability,  documentation  stan¬ 
dards,  maximum  computer  resources  allowable,  maintenance, 
and  program  transfer  capabilities. 

--  Agencies  quickly  oyercommit  themselves,  and  fail  to 
adhere  to  strict  phasing  to  control  contractors. 

Phasing  divides  the  development  effort  into 
logical  and  manageable  work  phases.  One  of  the  most  effec¬ 
tive  controls  available  to  an  agency  is  in  the  contractual 
identification  of  phases,  coupled  with  manadatory  agency 
review  and  approval  following  each  phase  as  a  precondition 
to  the  contractor’s  continuation  of  subseguent  phases.  Other 
advantages  associated  with  phasing  include: 

--  Identification  of  milestones  and  timetables  to 
monitor  the.  progress  of  the  project,  allowing  for 
the  initiation  of  corrective  actions  in  a  timely 
fashion. 

--  Systematic  and  orderly  development  of  software. 

—  Control  of  funds  based  upon  quality  and  accept¬ 
ability  or  contractor's  work. 

--  Increased  assurance  that  should  development  efforts 
are  being  used. 

—  Improved  communication  between  the  agency  and  the 
contractor  leading  to  the  Increased  probability 
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that  the  contractor  fully  understands  the  agency* s 
requirements. 

—  Completed  phases  provide  an  adequate  base  upon 
which  subsequent  phases  can  be  built. 

—  Lack  of  agency  management  during  contract 
execution. 

An  excessive  number  of  system  changes  were 
requested  by  the  agencies  in  the  cases  studied  by  GAO.  These 
agency-initiated  changes  ranged  in  scope  from  minor  require¬ 
ment  adjustments  to  re-resign  of  the  entire  system.  Many  of 
these  changes  requested  and  made  during  the  latter  phases  of 
development  and  contributed  significantly  to  cost  and 
schedule  overruns. 

Project  managers  should  be  aware  of  the  need  for 
a  well-defined  problem  statement  and  the  undermining  effects 
that  changes  have  cn  software  development.  Changes,  as 
compared  to  the  original  requirement  specification,  are  not 
usually  as  thoroughly  researched  and  may  cause  unforeseen 
and  rippling  effects  on  other  parts  of  the  system.  The 
systematic  and  logical  flow  of  contract  phasing  may  be  lost 
due  to  the  need  to  modify  work  that  has  already  been 
completed  and  approved,  obscuring  the  visibility  of  the 
projects  status.  Furthermore,  excessive  changes  make  it 
difficult  to  hold  the  contractor  accountable  for  the  initial 
terms  of  the  contract. 

--  Agencies  to  not  adequately  inspect  and  test  software. 

As  depicted  in  figure  2.1,  most  of  the  software 
delivered  in  the  cases  studied  was  of  poor  quality.  Reasons 
for  this  poor  quality  was  evidenced  in  ail  phases  of  devel¬ 
opment.  Quality  assurance  must  be  tied  directly  to  the 
contractual  process.  Higher  quality  software  can  be 
obtained  if  the  contractor  maintains  quality  assurance  func¬ 
tions  in  a  number  of  software  development  areas.  Specific 
examples  of  these  areas  include  configuration  management, 
testing,  program  design,  documentation,  and  working  tasks. 


The  latter  of  these  area,  working  tasks,  is  a  means  for 
assuring  that  procedures  are  in  affect  for  subdividing  the 
total  work  effort  into  segments  and  assigning  responsibility 
for  the  initiation  and  completion  of  work. 


NINE  SOFTWARE  DEVELOPMENT  CONTRACTS  TOTALING  $  6.8  MILLION: 

WHERE  THE  MONEY  WENT. 


■  SOFTWARE  THAT  COULO  BE  SOFTWARE  THAT  COULO 

USED  AFTER  CHANGES  ■BH  BE  USED  AS  DELIVERED 

(SI 90,000)  (11 10,000  out  of  SB  .S' million) 


Figure  2. 1  Value  of  Delivered  Software 


The  GAO  report  concluded  by  stating  the  need  for 
improvements  in  contracting  for  custom  software  development. 
Recommendations  were  made  aimed  primarily  at  GSA  and  NBS  for 
both  improvements  is  both  procurement  and  technical  areas. 

GAO  further  recommended  that  GSA  and  NBS  work 
together  in  designing  model  contracts  of  various  types. 
These  contracts  would  have  sample  clauses  for  covering  the 
withholding  of  payments,  testing,  etc..  Agencies  would  used 
these  samples  to  extract  those  clause  which  best  fit  there 
particular  requirements. 

The  last  recommendation  that  GAO  made  was  that 
Federal  agencies  that  extensively  contract  for  software 
development  "should  train  project  managers  in  appropriate 
software,  contracting,  and  management  skills."  [Ref.  5  :  p. 
29] 

2.  2j}§  llJlliAzfi mss  2&S&  Distribution  (££££) 

Report 

The  MUDD  Report  [Ref.  6  :  pp.  1-28]  should  be 
considered  "reguired  reading"  by  all  present  ana  future 
project  managers  overseeing  software  development.  It  is  a 
case  study  of  Navy  software  development  practices.  The 
report  is  based  on  over  30  interviews  with  of  those  respon¬ 
sible  for  the  development  of  Navy  systems.  The  year-long 
study  uses  the  development  of  the  fictional  MOOD  system 
under  development  to  mirror  many  of  the  requirements  of  Navy 
tactical  systems  either  in  operation  or  under  development. 
It  chronicles  and  analyzes  the  decisions  made  on  the  soft¬ 
ware  development  effort.  The  MODD  Report  concludes  with  a 
set  of  recommendations  to  Navy  program  managers  for  avoiding 
the  pitfalls  described  in  the  report. 

The  issues  brought  to  light  in  the  MODD  report  are 
germane  to  those  problem  areas  found  in  large  and  complex 
system  development  efforts  which  typify  many  DoD  programs. 
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An  adequate  summation  can  not  be  given  of  the  MDDD  report 
which  can  do  it  justice.  It  should  be  read  in  its  entirety 
for  a  full  appreciation  of  Weiss'  recommendations  which  are 
directed  at  problem  areas  that  infest  the  fictional  MDDD 
system  development.  Most  of  the  recommendations  center  on 
various  types  of  interfaces,  such  as  the  interface  between 
the  Navy  and  contractor,  interfaces  between  people,  inter¬ 
faces  between  and  within  systems,  and  interfaces  within  the 
Navy. 


3-  £fi£  Systejn  l££tv££e 


The  John  Hopkins  University  Applied  Physics 
laboratory  (AP1/JH0) ,  in  conjunction  with  the  MITRE 
Corporation,  conducted  an  extensive  study  of  the  management 
of  weapon  systems  software  under  the  auspices  of  the  Office 
of  the  Secretary  of  Defense  [Hef.  27].  The  MITRE  and  APL 
study  team  reviewed  the  findings  of  ten  previous 
DoD-sponsored  studies  relating  to  software.  The  MITRE 
Corporation  concluded  that  the  "major  contributing  factor  to 
weapon  system  computer  software  problems  was  a  lack  ^ 
discipline  and  engineering  rigor  applied  consistently  to  the 
software  acquisition  activities."  [Ref.  7  :  p.  50]  Other, 
more  specific,  findings  of  included  in  the  MITRE/APL  study 
included  the  following:  [Ref.  7  :  pp.  50  -51] 


Frequent  contributors  to  software  cost  and  schedule 

?rowth  include:  (a)  poorly  formulated  initial  software 
equirements:  (b)  changing  requirements  and  require¬ 

ment  growth  during  the  development  phases;  (c),  false 
starts  and  need  to  educate  involved  organizat 
before  useful  output  can  be  obtained;  (d)  Ineffic 
use  (proliferation)  of  already  existing  resources; 
Inefficient  testing  and  verification  tools 
methods;  and  (f)  improper  use  of  standards 
guidance  documents  in  specific  procurements. 
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■There  is  a  general  need  for  better  identification  o 
software  terms,  measures  of  software  qualities,  an 
the  methods  for  measuring  them. 


■Software  technology 
sloping  a  softwa 


deve  . 

made  by  Industr 
require  applica 


improvements  particularly  aimed. at 
engineering  dii 


re  engineer! 
y ,  academia, 

lion  to  real 


scipline  are  bej.n| 


nd  the  services  bu 
military  systems  (in 


24 


•«Wi 


ivy- 

lTb' 


>:•> 


for 


addition  to  laboratory  or  experimental  systems) 
evaluation  and  confirmation. 

The  study  resulted  in  a  series  of  17  recommenda¬ 
tions,  each  of  which  was  directed  at  a  specific  problem 
area.  A  sample  of  these  recommendations  included;  [Ref.  7  : 
pp.  50-51] 


•Specify  that  major  computer  software  involved  in 
weapon  system  development  be  designated  “configuration 
items”  and  be  deliverable  during  full-scale  develop¬ 
ment. 


all  then  progresses  to 
lower  levels. 


design  and 


__  _  prograi 

test  successively 


•Require  th$  contractor  to  apply  a  highly  disciplined 
jt  of  engineering  practices. 


sei 


!stabli$h  a  common  set  of  requirements  and  criteria  to 
)e  applied... by  all  services. 


■prepare  a  series  of  handbooks  of  guides 
important  aspects  of  software  acquisition. 


covering 


While  extensive  progress  has  been  made  in  DoD  toward 
addressing  many  of  the  problem  areas  noted  in  the  preceding 
studies,  much  work  remains  to  be  completed.  Specific  correc¬ 
tive  actions  that  have  been  adopted,  or  which  are  presently 
in  the  formulation  stages,  will  be  covered  in  this  thesis, 
part icularily  in  the  chapters  addressing  standardization  and 
the  STARS  software  initiative. 
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A.  BACKGBOUHD 

"You  can’t  contrcl  what  you  can’t  measure."  [Ref.  8  : 

P.  3]  A  disparity  exists  between  the  software  manager’s 
definition  of  what  constitutes  a  project’s  success  as 
compared  to  the  user's  perception  of  the  same  project.  With 
software  projects  resulting  in  utter  failures  or  cost  over¬ 
runs  of  two,  to  three,  times  the  original  estimate,  software 
managers  often  consider  their  projects  a  success  if  overruns 
are  kept  below  30%  and  when  "most"  of  the  delivered  lines  of 
code  are  considered  "usable"  by  the  end-user. 

DeMarco  [Ref.  8  :  p.  4]  writes  that  many  projects  fail 
event hough  the  project  managers  have  excelled  in  those 
characteristics  that  he  associates  with  good  management. 
These  characteristics  include: 

— project  staff  members  that  are  highly  motivated 
--clear  understanding  of  the  issues 
--adeguate  grasp  of  relevant  technologies 
--evident  capability  in  the  political  sphere 

Demarco  attributes  the  failure  of  these  project  managers  to 
the  fact  that  they  have  simply  failed  to  meet  the  original 
expectations  of  the  project.  He  is  convinced  that  in  often  it 
is  not  the  fault  of  the  project  team,  but  rather  the  fault  of 
"inflated  and  unreasonable  expectations."  When  expectations 
exceed  what  can  be  delivered,  the  project  is  doomed  to 
failure. 
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B.  CAUSES  FOR  POOR  SOFTWARE  ESTIMATING 


Estiaating  is  at  the  core  of  the  difficulties 
surrounding  software  projects.  Feedback  is  essential  for 
control.  Feedback  provides  a  basis  for  comparing  the  actual 
project’s  progress  against  original  expectations.  These 
expectations  were  formulated  on  estimates.  Main  causes  of 
poor  software  estimating  are  as  follows:  [Ref.  8  :  pp.  9  - 
17] 

1*  li£iS  £X£SE&&£» 

The  average  software  manager  will  typically  rate 
himself/herself  well  below  average  as  an  estimator.  The 
underlying  reason  for  this  is  simply  lack  of  estiaating 
practice  or  experience. 

The  amount  of  actual  estiaating  that  a  typical  soft¬ 
ware  manager  is  involved  in  will  normally  take  up  less  than 
3S  of  his/her  time.  Most  software  projects  may  call  for 
estimates  at  their  beginning,  and  maybe  once-a-month  or 
prior  to  management  review  thereafter. 

2.  Biases  Estimating 

Eersonal  biases  create  a  strong  tendency  to  underes¬ 
timate  one’s  own  potentials.  However,  when  objectively  esti¬ 
mating  another’s  potential,  then  most  of  these  biases  are 
minimized.  DeMarco  suggests  an  obvious  approach  to  avoid 
this  phenomenon  by  stating 

"Whoever  does  the  estimating  for  a  project  must  be 
someone  whose  entire  ego  involvement  is  in  the  quality 
of  the  estimate,  rather  than  in  the  project  itself...." 

[ Ret.  8] 


3.  £££i  2a4smaJid£iis  2£  £fi£Ai ais  nsan§. 


At  the  very  heart  of  probability  theory  is  the  esti¬ 
mation  of  "odds”  of  the  occurrence  of  a  certain  event.  Yet 
software  estimates  are  often  void  of  any  explicit  probabi¬ 
listic  assessment  which  may  govern  them.  This  observation  is 
closely  linked  to  preceding  subsection  on  the  personal 
biases  involved  in  estimating.  Should  a  software  manager  be 
asked  the  probability  of  finishing  a  project,  say,  20*  later 
that  s/he  originally  estimated,  an  answer  (right  or  wrong) 
will  freely  be  given.  On  the  other  hand,  should  the  same 
person  be  asked  the  probability  of  completing  the  project 
earlier  than  originally  estimated,  the  estimator  will  likely 
give  it  a  zero  probability.  This  represents  what  DeMarco 
[Ref.  8  :  p.  14]  terms 


Default  Definition  q£  "Estimate11 

An  "estimate"  is  the  most  optimistic  prediction  that 
has  a  non-zero  probability  of  coming  true. 


Instead,  DeMarco  [Ref.  8  :  p.  22]  proposes  that  an  estimate 
should  be  defined  as  "a  prediction  that  is  equally  likely  to 
be  above  or  below  the  actual  result."  This  definition,  by 
itself,  does  not  solve  the  estimating  problem.  It  does, 
however,  offer  a  basis  from  which  to  start  examining  meas¬ 
ures  and  other  components  of  estimates  which  will  be  covered 
in  this  chapter. 


4*  ISlAjaiSS  &S  M§£§  £21  lUS&MUXSM 

Often  estimates  are  used  to  establish  goals  for 
performance.  When  used  in  this  manner,  the  software  manager 
is  likely  to  establish  estimates  on  previously  established 
goals.  To  serve  as  a  motivational  tools  for  the  development 
staff,  the  goals  are  set  at  unattainable  levels. 
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Many  managers  view  goal-oriented  estimates  as  the 
supreme  motivational  mechanism  for  their  overly-optimistic 
development  staff  vhcse  self-esteem  is  placed  on  the  line  in 
the  pursuit  of  unachieveable  goals.  As  the  development  staff 
is  driven  toward  the  completion  deadline,  the  ultimate 
victim  of  of  this  motivational  strategy  is  the  guality  of 
the  finished  product  itself. 

C.  SOFTWARE  METRICS 

The  first  part  of  this  chapter  has  done  little  more  than 
point  out  many  of  the  ill-fated  approaches  which  have  tradi¬ 
tionally  been  used  tc  control  software.  These  approaches 
were  principally  qualitative  in  nature,  having  no  formal 
mathematical  basis.  Yet,  intuitively,  a  direct  relationship 
exists  between  software  quality  and  quantitative  software 
characteristics  such  as  modularity,  size,  and  logical 
paths.  As  such,  software  metrics  have  been  advocated  by  many 
authors  as  a  preferred  means  for  deriving  inputs  for  the 
estimating  process. 

This  section  will  examine  two  of  the  most  popular  theo¬ 
ries  in  software  metrics  that  have  grown  out  of  the  forma¬ 
tive  years  of  software  engineering:  (1)  Halstead's  Software 
Science  Theory,  and  (2)  McCabe's  Complexity  Measure. 
Appendix  B  provides  sample  algorithms  and  respective 
formulas  for  each  of  these  two  theories. 

1.  Uals£§a&!S  £&&&££  SSlgflfig 

The  first  set  of  metrics  to  be  reviewed  were  devel¬ 
oped  by  Maurice  K.  Halstead  [Ref.  9].  Instead  of  using 
"lines  of  code"  (LOC's)  to  describe  the  size  of  a  module, 
Halstead  breaks  each  line  down  into  a  series,  or  group,  of 
symbols.  Each  of  these  symbols  can  be  classified  as  either 
an  "operator"  of  as  an  "operand."  An  operand  is  a  single 


symbol  or  group  of  symbols  that  identifies  the  constants  or 
variables  that  the  module  uses  to  implement  its  algorithm. 
An  operator  is  a  single  symbol  or  group  of  symbols  which 
affects  the  value  of  the  operand.  Operators  also  impact  the 
sequence  in  which  the  operation  takes  place. 

Criticisms  concerning  Halstead's  theory  of  measuring 
through  the  use  of  operators  and  operands  were  guickly 
registered.  The  majority  of  Halstead's  work  evolved  around 
algorithms  drawn  from  Algol  and  FORTRAN.  In  other  algo¬ 
rithmic  languages,  the  definitions  of  operands  and  operators 
are  not  nearly  as  clear.  Halstead  also  omitted  declarations 
and  comments  from  his  calculations--a  significant  portion  of 
the  widely-used  COBOL  language.  Other  studies,  however,  have 
shown  that  the  additional  declarations  and  comments  actually 
brought  the  estimated  program  length  closer  in  line  with  the 
actual,  completed  program.  In  any  case,  it  is  important  to 
identify  the  operands  and  operators  of  an  algorithmic 
language  to  establish  consistency.  This  function  can  often 
be  determined  by  a  compiler,  through  which  the  operators  and 
operands  are  explicitly  defined  in  the  final  machine 
language  product.  Questions  abound  on  the  derivation  of 
Halstead's  formulas.  The  validity  of  his  experiments  has 
been  questioned  because  of  the  small  sample  size,  the  small 
size  of  the  programs  used,  and  the  subjects  used  were 
college  students  vice  experienced  programmers. 

Halstead  proposes  that  each  language  can  be  categor¬ 
ized  by  a  language  level,  1,  which  will  vary  among 
languages.  The  variances  are  closely  linked  to  the  level  of 
abstraction  by  which  a  procedure  can  be  specified.  Halstead 
assigns  a  constant  language  level  for  a  particular  language, 
which  is  in  contrast  by  to  the  recent  works  that  show  that 
language  level  is  a  resulting  product  of  both  the  language 
and  the  programmer.  Table  2  provide  the  language  levels 
values  that  have  been  empirically  derived  for  five  common 
languages  [Ref.  1:  p.  166]. 
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TABLE  2 

Language  Level 

Values 

Language: 

Mean  1 

English  pose 

2.16 

1.53 

ALGOL/66 

FORTRAN 

:?! 

Assembler 

0.88 

2.  jjggflfeaal  C2fi£iexiti  fleisjjts 


In  his  article,  [Ref.  12  :  PP.  308  -320]  McCabe 
proposes  a  complexity  measure  of  software  which  Is  based 
upon  the  control  flow  representation  of  a  program.  Through 
the  analysis  of  several  FORTRAN  programs,  he  illustrates  a 
high  correlation  between  the  intuitive  complexity  of  a 
program  and  his  proposed  graph-theoretic  complexity  measure. 

McCabe* s  software  complexity  measure  is  preported  to 
measure  and  control  the  number  of  paths  through  a  program. 
The  primary  difficulty  is  this  regard  is  manifested  through 
backward  branches  which  may  possibily  result  in  an  infinite 
number  of  paths  during  program  execution.  Conseguently , 
using  a  path  count  to  measure  program  complexity  is  inprat- 
ical.  However,  the  complexity  measure  can  be  defined  in 
terms  of  basic  paths,  that  when  taken  in  combination,  will 
measure  every  possible  path. 

As  compared  to  Halstead* s  metrics,  McCabe* s 
complexity  measure  can  be  applied  during  the  earlier  stages 
of  software  development  since  it  is  not  dependent  on  the 
measurement  of  code.  The  cyclonatic  complexity  measurement 
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provides  an  evaluation  tool  by  which  "goodness"  of  a  module 
can  be  reviewed  following  its  detailed  design  [  Hef.  1  :  p. 
169  ]. 

D.  SOFTWARE  COSTIHG 

The  role  of  software  in  the  military  and  private  sector 
has  grown  considerably  during  the  past  decade.  During  the 
infancy  cf  computing/  software  cost  amounted  to  only  a  small 
percentage  of  the  overall  computer  system.  Today,  software 
is  the  most  significant  portion  of  most  computer  systems. 
Accurate  estimates  cf  software  development  cost  seldom 
occur,  with  the  final  costs  normally  running  considerably 
higher.  There  are  two  fundamental  problems  which  make  accu¬ 
rate  estimates  of  software  development  costs  most  difficult 
[Ref.  13  :  p.  45].  These  are: 

—  the  high  risks  and  uncertainties  involved  in  software 
development 

—  the  lack  of  a  quantitative  data  base  for  previous 
cost  estimates  and  final  costs.  i.e.,  "lessons 
learned" 

In  spite  of  these  significant  problems,  cost  estimate  are  made 
and  will  continue  to  be  made  with  varying  degrees  of  accuracy 

This  section  will  describe  three  current  methods  of  cost 
estimating  and  provide  a  table  for  their  comparison  based  on 
application  (Ref.  13  :  p.  15  -  17]. 

i  -  teal&ax 

This  method  estimates  the  costs  for  a  new  system 
based  upon  the  the  costs  of  a  similar  system.  The  cost  esti¬ 
mate  is  adjusted  to  compensate  for  any  differences  between 
the  two  systems  being  compared.  The  analogy  method  is  fairly 
simple  provide  accurate  cost  data  for  the  existing  system  is 
available  and  the  development  methods  and  resources  are 
similar. 


2 •  pegomposltiop 


As  the  method  name  suggests,  a  system  is  broken  down 
into  components  and  subcomponents  until  the  level  of  decern* 
position  makes  it  possible  to  estimate  the  costs  fairly 
accurately.  One  approach  of  decomposition  uses  the  analogy 
method  previously  described.  In  this  approach,  the  process 
of  decomposition  is  effectuated  until  the  resulting  level  of 
decomposition  can  be  compared  with  a  similar  component  which 
already  exists.  A  second  approach  of  decomposition  divides 
the  system  into  components  for  which  a  level  of  effort  can 
intuitively  be  estimated  for  each  kind  of  activity  that  is 
needed  to  produce  that  component.  This  latter  type  of  decom¬ 
position  normally  depends  heavily  upon  the  technical  knowl¬ 
edge  and  experience  of  the  estimater  The  preassumption  that 
underlies  this  method  of  cost  estimating  is  that  the  costs 
for  small  systems,  or  components,  can  be  accurately  made. 
The  total  system  is  perceived  as  the  aggregate  total  of  its 
subsystem. 

3 .  &££l£t£ic  HfiiSis 

As  with  the  analogy  method,  the  parametric  model 
approach  to  cost  estimating  is  also  heavily  dependent  on  the 
accumulation  of  past  and  accurate  cost  data  for  software 
development.  Analyses  of  cost  data  permits  the  identifica¬ 
tion  of  cost  variables  and  a  guantif ication  of  their  rela¬ 
tionship  to  cost.  Any  new  cost  estimate  can  be  derived  by 
estimating  the  assigned  values  of  the  cost  variables.  Once 
this  is  done,  the  cost  can  be  calculated  using  the  equations 
which  express  the  cost  estimating  relationships.  The  advan¬ 
tages  of  this  method  is  that  it  allows  for  a  rapid  determi¬ 
nation  of  cost  estimates,  using  parameters  whose  values  can 
be  easily  modified. 
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Table  3  [fief.  13  :  p.  16]  provides  a  comparison  of 
the  three  cost  estimating  methods  discussed.  Combinations  of 
two,  or  wore,  methods  may  be  used  together,  or  separately  to 
test  the  validity  of  an  estimate.  Resultant  differences  are 
adjusted  to  arrive  at  a  reasonable  estimate 


TABLE  3 

Comparison  of  Cost  Estimating  Methods 

ix££  mo&mm 

Analog  Compare  to  prior  system 

Decomposition  Divj.de  into  parts, 

&Ctl7X tl 6 s 


Parametric  Equations  based  on  prior 

Models  data  about  cost  relation** 

ships 


TYPE  GOOD  FOR 


Analog 


Decomposition 


Parametric 

Models 


similar  systems  with 
similar  resources, 
development  process 

resource  allocation 
unigue  systems 

rapid  estimation 

?stimater's  inexperience 
n  software  development 
estimating  risk 


TYPE 


£M  £££ 


Analog 


Decomposition 


Parametric 

Models 


unigue  systems 
different  environments 

initial  estimates  with  no 
design 

rapid  estimation 

systems  different  from 
data  sample 

poorly  correlated  data 
base 


Automated  costing  systems  provide  another  option  for 
estimating.  In  these  automated  systems,  the  characteristics 
of  the  development  organization,  such  as  the  staff's  experi¬ 
ence  level,  and  characteristics  of  the  software  to  be  devel¬ 
oped  are  described.  Cost  estimates  are  derived  from  this 
input  data.  As  with  the  other  three  manual  methods,  the 
derived  cost  data  will  only  be  as  good  as  the  empirical  d.ata 
upon  which  it  is  founded.  If  no  historical  data  exists, 
then  the  validity  cf  the  cost  estimates  is,  indeed, 
questionable. 

E.  CHAPTER  SUMMARY 

McCabe's  and  Halstead's  software  metrics  remain  a 
controversial  topic.  But  they  do  represent  a  revolutionary 
approach  toward  providing  software  managers  with  quantita¬ 
tive  functions  for  estimating  many  heretofore  elusive  char¬ 
acteristics  of  software.  The  validity  of  Halstead's 
experiments  have  yet  to  be  significantly  tested.  For  those 
tests  that  have  been  performed,  the  size  of  the  programs 
were  generally  small,  and  the  subjects  were  college  students 
vice  professional  software  developers. 

As  compared  to  Halstead's  metrics,  McCabe's  complexity 
measure  can  be  applied  during  the  earlier  stages  of  software 
development  since  it  is  not  dependent  on  the  measurement  of 
code.  The  cyclomatic  complexity  measurement  provides  an 
evaluation  tool  by  which  "goodness"  of  a  module  can  be 
reviewed  following  its  detailed  design.  Despite  the  criti¬ 
cisms  that  normally  abound  the  proposition  of  new  theories, 
both  Halstead's  and  McCabe's  metrics  represent  a  giant  leap 
toward  adding  quantitative  measurements  to  a  discipline  that 
has  defied  them. 

The  military's  justified  and  growing  concern  over 
frequent  cost  overruns  for  software  development  is  forcing 
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changes  in  both  the  management  and  development  of  software. 
As  such,  new  requirements  and  changes  can  be  expected  that 
will  provide  a  more  uniform  and  better  control  over  cost  and 
software  development.  This  chapter  has  addressed  three  of 
the  most  common  software  cost  estimating  methods.  The  STARS 
program.  Chapter  VII,  addresses  a  DoD-sponsored  software 
initiative  which  will  significantly  alter  and  guide  future 
software  development  efforts  for  DoD  weapon  systems. 
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iv.  swill  zouim 


"Software  correctness  remains  the  most  elusive 


:ware  correct 
iter  science. 


computer  science.  As  a  result,  software  is  the  most 
unsafe,  the  least  understood,  and  the  most  expensive 
component  of  total  computer  system  cost.  In  contrast, 

Sosc  of  computer  circuitry  have  shown  a  dramatic 
ecrease,  especially  in  the  past  15  years,  and  computer 
hardware  capability  has  improved."  [Ref.  14  :  p.  16] 


ost  elusive  goal  of 
oftware  is  the  most 
the  most  expensive 
cost.  In  contrast. 


A.  BACKGBOUHD 


The  preceedi&g  quotation  was  taken  from  an  article 
authored  by  the  Deputy  Under  Secretary  of  Defense  (Research 
and  Advanced  Technology),  Dr.  Ruth  Davis.  It  expresses  the 
concerns  shared  by  many  DoD  top  officials  relating  tc  the 
both  cost  and  safety  risks  associated  with  the  development 
of  today’s  computer  systems. 

As  a  percentage  of  total  computer  system  cost,  it  is 
generally  known  that  the  cost  of  hardware  has  decreased 
dramatically  over  tie  the  past  15  years  while  the  cost  of 
software  has  steadily  increased.  Today,  software  represents 
approximately  90*  of  the  total  computer  system  [  Raf .  14  s  p. 
18].  There  are  two  basic  reasons  to  explain  the  change  in 
the  cost  ratio  between  hardware  and  software.  These  are: 
[Ref.  15  :  pp.  55  -  56] 


(1)  Size:  Today’s  software  programs  are  an  order  of 

magnitude  larger  than  they  were  two  decades  ago. 
This  can  be  attributed,  in  part,  to  the  increase  in 
size  (and  simultaneous  decrease  in  the  cost)  of 
onboard  memory.  An  adaptation  of  Parkinson’s  law 
suggests  that  program  instructions  will  continue  to 

I|m»  aSSIlJli.cor.  ii1?.*!,  l5?hlie1?uent  ly  bey0nd) 


(2)  Complexity :  As  nature  gf  the  applications  being 

ITItolaTea  today  are  considerably  more  sophisticated 
than  those  applications  of  yesteryear.  Both  mili¬ 
tary  .  and  ccmmercia.’  survival  strategies  are 
becoming  increasingly  dependent  on  maintaining  the 
competitive  edge  in  computer  superiority. 
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Software  has  become  a  primary  vehicles  for  solving  many 
of  the  new  and  changing  problems  facing  the  military.  Zn 
many  cases,  changes  to  software  is  often  viewed  as  an  effi¬ 
cient  and  expedient  way  to  solve  a  variety  of  emerging  prob¬ 
lems  or  threats  facing  Do D  without  having  to  change  the 
existing  hardware.  Yet  the  virtues  of  software  are  often 
outweighed  by  its  associated  problems  as  described  in 
chapter  II. 

It  is  not  suprising  that  DoD  has  identified  software  as 
the  most  significant  factor  in  determining  the  total  cost  of 
computer-  based  systems  over  their  life  cycles.  Numerous 
studies  have  been  conducted  which  show  software  guality  as 
one  of  the  most  significant  factors  determining  the  life 
cycle  cost  of  software.  This  chapter  will  present  many  of 
the  characteristics  cf  software  guality  and  the  means  to 
achieve  them. 

B.  DEFINING  SOFTNESS  QUALITY 

Defining  guality  software  is,  in  itself,  a  task.  There 
are  as  many  definitions  of  what  makes  software  "good"  as 
there  are  authors  that  write  about  it.  Yet  these  definitions 
are  not  mutually  exclusive.  Each  author  has  his  own  ideas  of 
what  the  principle  characteristics  of  guality  software  are, 
and  each  is  right.  Defining  guality  software  is  as  difficult 
as  defining  the  virtues  of  mankind.  Air  Force  Regulation 
(APR)  74-1,  the  "Air  Force  Quality  Assurance  Program," 
broadly  and  sensibly  defines  guality  cs  "The  composite  of 
material  attributes  including  performance."  Other,  more 
specific,  definitions  advocated  by  many  of  the  "gurus"  of 
software  engineering  will  now  be  discussed. 

Pressman  [Ref.  1  :  p.  148]  suggests  that  good  software 
has  three  essential  gualities: 

—  the  software  works  according  to  the  specified 
reguirements —  being  as  fast,  efficient,  and  as  func¬ 
tional  as  needed. 


can  be  diagnosed  and 
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the, software  is  more  than  merely  lines  of 
includes  all  the  supporting  documents  to  en 
the  first  two  Qualities  are  achievable. 


f  code-rit 
nsure  that 


According  to  Pressman,  good  software  is  based  upon  good 
design,  and  good  design  can  be  gauged  by  applying  a  number  of 
software  engineering  measures  and  heuristics. 

DeMarco  [Hef.  8  :  pp.  198  -  200]  prefers  to  define  soft¬ 
ware  guality  as  "the  absence  of  spoilage"  [Hef.  8  :  p.  200], 
with  the  term  "spoilage"  meaning  the  amount  of  effort 
reguired  to  find  and  remove  faults  introduced  during  the 
software  development  process.  Eguating  this  amount  of  effort 
to  its  commensurate  cost,  Demarco  provides  a  formula  to 
guantify  software  guality:  [Ref.  8  :  p.  200] 


Quality 


Summation  of  Defect  Diagnosis  and  Correction  Cost 


Program  Volume 


C.  CHARACTERISTIC  OP  SOFTWARE  QUALITY 

One  of  the  most  comprehensive  and  significant  works 
written  to  provide  a  framework  for  assessing  the  issues 
associated  with  software  guality  is  found  in  the  study 
conducted  by  Boehm,  et  al. ,  titled  Characteristics  of 
Polity  Software  [Hef.  16].  This  section  will  present  many 
of  the  highlights  reported  by  this  study. 

In  developing  a  methodology  for  the  assessing  the 
guality  of  software  products,  the  authors  concluded  that 
"calculating  and  understanding  the  value  of  a  single  overall 
metric  for  software  guality  may  be  more  trouble  than  it  is 
worth."  [Hef.  16  :  p.  3-2]  A  major  problem  in  developing  a 
single  metric  for  gauging  the  guality  of  software  is  that 
many  of  the  characteristics  of  software  are  in  conflict  with 


one  and  another.  For  example,  regu.iring  a  high  degree  of 
software  portability  is  achieved  at  the  expense  of  software 
efficiency.  Code  conciseness  is  at  odds  with  maintain¬ 
ability,  under standability,  and  so  forth.  As  such,  the  study 
developed  a  relational  set  of  important  software  character¬ 
istics  which  were  reasonably  exhaustive  and  non-  overlap¬ 
ping.  This  set  of  characteristics  would  serve  to  define  a 
working  context  for  collection  and  formulation  of  a  set  of 
candidate  metrics  used  to  assess  the  degree  to  which  the 
software  possessed  the  respective  characteristic.  Figure  4. 1 
shows  the  resulting  characteristic  set  and  their  hierarchial 
interrelationships  [  Bef .  16  :  p.  3-19].  Definitions  for 
each  of  the  represented  characteristics  is  provided  in 


Figure  4.1  Characteristics  Tree 


appendix  A.  The  characteristics  depicted  in  Figure  4.  1  are 
categorized  in  three  hierarchial  levels.  The  higher-level 
structure  is  oriented  toward  accommodating  various  user 
needs  and  priorities  for  a  software  product.  For  example, 
"As-is"  utility  is  analogous  to  the  "black  box"  under¬ 
standing  of  a  system;  the  user  is  concerned  with  only  the 
inputs  and  outputs  of  the  product  and  need  not  understand 
the  its  internal  code,  nor  how  to  modify  or  test  it.  If  the 
product  is  going  to  be  changed  by  the  user,  then  maintain¬ 
ability  reguire3  that  the  user  be  able  to  understand, 
modify,  and  test  the  product. 

The  lover- level  structure  depicts  those  primitive  char¬ 
acteristics,  which,  although  strongly  differentiated  from 
each  other,  "combine  into  sets  of  necessary  and  sufficient 
conditions"  (Ref.  16s  p.  3-25]  to  define  the  intermediate- 
level  characteristics.  The  primitive  characteristic  provide 
the  foundation  for  formulating  the  metrics  used  to  quantifi- 
ably  measure  a  software  products  relative  possession  of 
those  characteristics  described  in  both  the  high —  and 
intermediate  layers. 

D.  QUALITY  ASSURANCE 

The  proceeding  section  described  many  of  the  attributes 
associated  with  good  software,  as  well  as  their  interrela¬ 
tionships.  The  purpose  of  this  section  is  to  offer  a  frame¬ 
work  through  which  quality  software  can  be  achieved  through 
planning,  specification,  and  monitoring  of  quality  assurance 
(QA)  activities. 

The  purpose  of  software  quality  assurance,  in  short,  is 
to  assure  the  ultimate  quality  of  the  delivered  software.  A 
formal  definition  of  quality  assurance  is  provided  by  AFR 
74-1,  which  defines  it  as: 


t  w  vwiwv’i  w*i 


"  A  planned  and  systematic  pattern  of  all  actions  neces¬ 
sary  to  provide  adequate  confidence  that  material,  data, 
supplies,  ana  services  conform  to  established  technical 
requirements  and  achieve  satisfactory  performance." 


Another  definition  for  quality  assurance  is  offered  by  Pfau 
[Ref.  17  ;  p.  2]  who  also  helped  remove  some  of  the  subjec¬ 
tivity  that  surrounds  the  term  "guality"  by  stating: 


"Quality  assurance  is  the  name  given  to  the  activities 
performed  In  conjunction  with  a  software  product  to 
guarantee  the  product  meets  the  specified  standards. 
These  activities  reduce  doubt  ana  risks  about  the 
performance  of  the  product  in  the  target  environment." 


Both  of  the  above  definitions  are  reflective  of  the  direc¬ 
tion  that  QA  has  taken  over  the  past  two  decades  toward  a 
total  life-cycle  perspective.  This  evolution  of  QA  has  been 
divided  into  three  separate  generations  [Ref.  18  :  pp.  2  - 
a].  It  is  important  to  understand  the  differences  in  these 
generations  in  order  to  avoid  the  serious  pitfalls  implic¬ 
itly  and  explicitly  expressed  in  the  first  two. 

First  Generation — Test-Oriented  QA:  This  QA  generation 
basically  equated  QA  to  software  test  programs.  Tests  plans 
and  procedures,  types  of  test,  and  methods  of  formal  verifi¬ 
cation  of  performance/design  requirements  were  all  essential 
to  the  testing  activity. 

The  cbvious  and  major  pitfall  of  the  test-oriented  QA 
generation  is  that  "you  don't  test  quality  into  a  software 
product."  [Ref.  18  :  p.  2]  Even  though  testing  facilitated 
the  discovery  of  deficiencies,  the  discovery  normally  took 
place  too  late  in  the  development  process  to  allow  their 
relatively  inexpensive  resolutions. 

Sfcojid  Sengiationr-Dey^o^ment^O^ieated  QA:  Due  to  the 
inherent  failure  mechanisms  built  into  test-oriented  QA, 
corrective  actions  were  taken  by  an  attempt  to  make  the 


developing  contractor  responsible  for  the  quality  shortcom¬ 
ings  of  the  products  they  produced.  This  was  done  by 
assuring  that  the  software  delivered  under  contract  fully 
complied  with  the  requirements  of  the  contract. 

The  pitfall  to  this  QA  approach  is  as  limited  as  the 
contracting  officer  technical  knowledgeable  in  the  kroad 
discipline  of  software  engineering.  Contract  delivered  what 
was  specified,  nothing  more. 

XJl&d  2fia§£ati2I!~Ul£c£l£le-gEi§nied  QA:  In  this 
generation,  QA  is  built  into  the  software  from  "day  one." 
The  effort  is  properly  focused  on  the  early  definition 
phases  for  planning  and  specifying  contractual  provisions 
concerning  software  attributes.  Figure  4.2,  [Bef.  1  :  p.  25] 
illustrates  the  cost  impact  of  introducing  changes  during 


Figure  4.2  Cost  Impact  of  Changes 

various  phases  of  the  software  life-cycle.  Emphasis  is 
placed  on  the  clear  definition  of  those  software  character¬ 
istics  that  were  discussed  in  the  first  section  of  this 
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chapter,  such  as  maintainability  and  portability,  which  have 
a  significant  affect  on  the  guality  of  the  product  over  the 
system's  life-cycle.  The  importance  of  the  life-cycle- 
oriented  QA  approach  and  its  impact  on  life-cycle  costs 
following  software  development  and  implementation  is 
discussed  at  length  in  the  chapter  on  software  maintenance. 

I.  1 HP1EMENTATIOH  OP  A  SOFTWARE  QUALITY  ASSURANCE  PROGRAM 

The  proceeding  section  addressed  the  definition  of  soft¬ 
ware  guality  assurance,  as  well  as  its  evolution  to  the 
present  life-cycle-oriented  perspective  which  recognizes 
that  to  achieve  the  highest  guality  of  software  it  is  neces¬ 
sary  to  include  guality  checks  throughout  all  phases  of  the 
software  life-cycle. 

This  section  will  discuss  the  military  standards  for  the 
implementation  of  software  guality  assurance  (SQ A)  programs 
in  defense  contracts.  The  successful  implementation  of  these 
programs  will  provide  early  •  visibility  and  managerial 
controls  to  detect,  report,  analyze,  and  correct  software 
deficiencies.  Although  the  focus  of  this  discussion  will  be 
on  defense  contracts,  the  methods  addressed  herein  may  be 
equally  beneficial  to  in-house  development  efforts. 

The  two  most  significant  military  standards  affecting 
the  establishment  of  SQA  programs  for  defense  contract  are: 
(1)  MI1-STD-52779 (A) ,  "Software  Quality  Assurance  Program 
Requirements,"  providing  the  basic  elements  required  in  an 
acceptable  SQA  program,  as  well  as  customer  evaluation 
criteria,  and  (2)  MIL-Sl'D-1679,  "Weapon  System  Software 
Development,"  providing  detailed  software  development  stan¬ 
dards  for  the  entire  weapon  system  software  development 
process.  Both  the  software  manager  and  procuring  agent 
should  be  familiar  with  their  contents  since,  together, 
these  standards  provide  an  effective  means  to  evaluate  any 
software  development  program  [Ref.  19  :  p.  108]. 


In  their  article  [fief.  19]#  Dobbins  and  Buck  discuss 
five  areas  of  control  which  follow  the  typical  chronology  of 
software  development.  These  are:  (1)  procuring  agency  evalu¬ 
ation#  (2)  design  inspection#  (3)  code  inspection#  (4)  test# 
and  (5)  library  controls.  The  remainder  of  this  section  will 
address  each  of  areas  separately. 

1.  Procuring  Agency  Evaluation 

From  both  a  cost  and  effectiveness  standpoint#  the 
conseguences  are  too  important  to  accept  at  face  value  the 
claims  that  a  strong  SQA  program  exists  in  their  organiza¬ 
tion.  There  must  exist  some  means  to  evaluate  the  potential 
contractor.  Major  guality  items  must  be  addressed  as  early 
as  possible  in  the  planning  process  prior  to  the  Reguest  for 
Proposal  (RFP)  preparation.  These  guality  items  should 
include  those  attributes  considered  as  an  integral  part  of 
the  software  design#  development#  test  and  evaluation#  and 
maintainability  issues.  Table  4  [Ref.  18  :  p.  33 ]  provides  a 
number  of  factors  with  which  to  evaluate  bidders'  responses 
to  the  RFP  process. 

Cften  the  program  manager  and  procurement  agency 
will  have  insufficient  experience  and  technical  background 
to  properly  identify  essential  QA  issues  needed  for  inclu¬ 
sion  in  the  RFP  nor  the  means  or  time  to  evaluate  the 
contractor  proposals.  In  these  situations  there  are  alterna¬ 
tives  resources  available  to  evaluate  the  contractor.  The 
first  of  these  is  the  Defense  Contract  Administrative 
Service  (DCAS) .  The  program  manager  can  hire  the  services  of 
software  engineers  acguainted  current  military  QA  standards. 
Depending  on  the  end-application  of  the  software  product# 
there  are  other  government  organizations  through  which 
assistance  can  be  sought.  Other  alternatives  include  hiring 
the  services  of  a  commercial  contractor  or  consulting  firm. 
Regardless  of  the  resource  used#  a  sound  means  for 
contractor  evaluation  and  selection  is  essential. 


TABLE  4 

Evaluation  Factors  in  Bidder  Responses 


FACTORS: 

Comp lateness 

Scope 

Compliance 

Documents 


Design  Review 
Board 

Event  Sequences 

Problem 

Reporting 

Action  Item 
Follow-Op 


Past  Experien¬ 
ce  s/Resources 


BIDDER  EVALUATION  CHECKLIST: 


Dees  bidder's  re 
area  as  re 


r's  respo 
guested  i 


nse  cover  all 
n  the  RFP? 


bidder's 
rith  the 


Is  the  scope  of  the 

response  consonant  w: _ 

proiect* s  objectives  and  the  level 
of  detail  in  the  RFP  ? 

Are  all  compliance  documents 
filntirild?  6  software  design 

Soes  the  bidder  propose  to  have 
esign  Review  boards? 

Are  the  reviews  of  software  design 
done  in  proper  sequence? 

Joes  the  bidder  propose  to  formally 
dentxxy  all  design  problems? 

Dees  bidder  provide  assurance  for 
effective  follow-up  of  all  action 
items  resulting  from  reviews? 

What  experience  does  the  bidder 
have  with  QA?  Does  he  have  a  good 
resource  base? 


2 •  isa 

Although  MIL-STD-1679  specifies  that  ‘'walkthroughs” 
should  be  used  as  the  means  to  collect  statistics  during  the 
design  phase  of  software  development,  the  process  has 
evolved  to  the  more  formal  procedure  termed  "design  inspec¬ 
tion."  The  difference  between  the  two  approaches  is  one  "of 


46 


rigor,  not  intent"  [Bef.  19  :  p.  110].  The  walkthroughs 
were  informal  examinations  of  the  software  product  by  its 
authors'  technical  peers,  little  documentation  was  kept,  and 
no  training  reguireoent  placed  on  the  participants  of  the 
walkthrough. 

As  with  the  walkthrough,  the  design  review  is  a  peer 
inspecticn  process  performed  by  teams  that  inspect  one 
another's  work.  Unlike  the  walkthrough,  the  design  review 
is  a  formal  process  in  which  records  are  kept,  and  partici¬ 
pants  undergo  considerable  training  requirements.  It  is 
conducted  when  the  design  is  completed,  prior  to  the  actual 
coding  effort.  The  inspection  team  is  led  by  a  moderator. 
The  ideal  moderator  is  not  only  trained  in  the  technical 
aspects  of  software  engineering,  but  in  the  psychological4 
aspects  of  software  development. 

The  moderator  promulgates  required  inspection 
material  to  the  team  in  advance  of  the  inspection.  Each  team 
member  reviews  the  material  and  records  comments  before  the 
inspection  meeting.  During  the  meeting,  discussion  is 
reserved  for  major  error,  i.e.,  those  errors  that  will 
prevent  the  program  from  functioning  properly.  Minor  errors 
simply  recorded  for  subsequent  correction.  If  more  than  5% 
of  the  program  design  must  be  changed  due  the  errors,  the 
entire  design  will  be  reinspected.  Otherwise,  the  moderator 
will  assure  that  the  errors  discovered  during  the  design 
inspection  are  corrected  before  proceeding  into  the  next 
phase. 


4For 
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Programming  coding  may  begin  only  after  successful  comple¬ 
tion  of  the  design  inspection.  MIL-STD-1679  requires  top- 
down  structured  programming  and  identifies  the  specific  code 
constructs  allowed.  Figure  4.3  [Ref.  20  :  p.  62],  illus¬ 
trates  the  five  basic  code  structures,  each  having  a  single 
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Figure  4.3  Basic  Code  Structures 
data  entry  and  exit. 

Cnee  the  program  is  coded  and  successfully  compiled, 
it  is  inspected.  The  process  for  inspecting  code  is  nearly 
identical  to  that  discussed  for  design.  Not  only  is  the  code 
inspection  a  method  cf  discovering  coding  errors,  but  just 
as  importantly  it  assures  that  the  code  coheres  to  the 
approved  design. 


4.  Test 


Software  testing  accounts  for  the  majority  of  technical 
efforts  expended  in  software  development.  Its  objectives  are 
to  uncover  software  errors,  and  to  provide  assurances  that 
the  software  performs  its  technical  and  operational 
requirements. 

An  effective  SQA  program  must  start  at  the  front  end 
of  software  development,  with  the  requirements  specified  in 
the  EFP,  addressing  the  totality  of  the  testing  tc  be 
performed.  Three  measures  of  software  testing  relating  to 
the  EFP  include:  [Bef.  A059H068  :  p.  19] 

(1)  The  analysis  of  software  requirements  for  test¬ 
ability. 

(2)  The  identification  of  the  contractor’s  software 
testing  activities  as  part  of  his  Software  QA 
Program. 

(3)  The  review  gf  test  documentation  and  certification 
cf  test  results. 

Testing  requirements  specified  in  MIL-STD-1 679 
require  that  the  system  software  do  more  than  just  just  meet 
the  specifications.  Software  must  also  be  subjected  to  a 
third-party8  "stress  test,"  in  which  the  program  is  judged 
unsatisfactory  if  the  program  execution  can  be  stopped  for 
whatever  reason.  To  achieve  a  degree  of  software  quality 
sufficient  enough  to  pass  this  type  of  testing,  it  is  vitu- 
ally  essential  that  the  software  development  program  incor¬ 
porate  programs  of  error  detection  and  prevention  well  in 
advance  of  the  actual  testing  period. 


8As  defined  in  HI1-STD-1 679,  the  third  party  is  neither 
the  contractor  nor  the  procurement  agency. 
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A  Key  element  in  any  SQA  program  is  the  software 
library  which  provides  visibility  and  control  of  the  prod¬ 
ucts  documentation  and  programs.  Among  the  mandatory 
controls  stipulated  by  fJII-S-52779  (A)  is  the  control  to 
prevent  unauthorized  access,  other  essential  activities  in  a 
software  library  are  the  documentation  and  program  storage, 
and  retrieval  and  change  processing.  MIL-STD-1679  requires 
a  Software  change  Control  Board  (SCCB) ,  which  must  authorize 
any  changes  to  the  controlled  library. 

F.  PASTING  COMMENTS 

The  underlying  goal  of  software  development  is  to 
deliver  quality  software.  in  doing  so,  it  is  vital  to 
examine  the  characterics  of  quality,  and  their  interrela¬ 
tionship,  within  the  context  of  the  user  needs  and  ultimate 
application  of  the  program.  To  understand  the  characteris¬ 
tics  of  quality  software  is  to  understand  the  founding  prin¬ 
ciples  of  software  engineering.  To  produce  quality  software 
is  much  more.  The  implementation  of  a  software  quality 
assurance  program  is  the  vehicle  through  which  these  princi¬ 
ples  are  applied  and  the  goal  of  software  development 
realized. 

The  benefits  derived  from  guality  software  support  the 
saying  that  "guality  is  free."  But  more  importantly,  as  will 
be  addressed  in  the  next  chapter,  future  cost-avoidance 
during  the  maintenance  phase  leaves  no  practical  alternative 
to  acceptance  of  only  guality  software. 


v.  ttzmu  auiualiss 


This  chapter  deals  with  the  last  phase  of  the  software 
life  cycle.  Canning  [Ref.  21  :  p.  2]  appropriately  categor¬ 
ized  software  maintenance  as  an  ’‘iceberg,"  initially 
revealing  only  a  small  portion  of  maintenance  requirements, 
but  hiding  an  enormous  potential  for  future  problems  and 
costs  under  the  surface.  With  few  exceptions,  computer 
programs  are  always  changing  in  order  to  correct  latent 
errors,  add  enhancements,  and  seek  performance  optimization 
of  the  software.  A  succinct  definition  for  maintenance  can 
be  given  as  "that  activity  which  is  concerned  with  making 
changes  to  software  for  the  purpose  of  improving  or 
correcting  the  software.”  [Ref.  22  ;  p.  2]  Maintainability 
is  defined  22  as  ”a  property  of  software  which  makes  the 
maintenance  activity  easy  to  perform,  i.e.,  changes  tc  the 
software  are  easy  to  incorporate  and  do  not  lead  to  new 
errors  in  the  software.”  This  chapter  will  primarily  address 
issues  of  maintainability  which  by  necessity  must  be  consid¬ 
ered  during  all  phase  of  the  software  life  cycle. 

A.  CATEGORIZATION  OF  MAINTENANCE  ACTIVITIES 

Maintenance  is  much  more  than  just  fixing  errors  that 
escaped  detection  during  the  pre-delivery  tests  and  evalua¬ 
tions.  Maintenance  has  been  categorized  [Ref.  1  :  p.  323] 
into  four  activities  that  take  place  after  the  program  is 
released  for  use.  These  are  corrective  maintenance,  adaptive 
maintenance,  perfective  maintenance,  and  preventive  mainte¬ 
nance.  Each  will  now  be  described. 

Corrective  maintenance  is  the  process  that  includes  the 
diagnosis  and  correction  of  latent  errors  that  avoided 
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detection  prior  to  the  implementation  of  the  program.  It  i3 
impractical,  if  not  impossible,  to  exhaustively  test  complex 
programs  in  order  to  guarantee  100%  error-free  software. 

Ad£I2JUl£  maintenance  are  those  modifications  nade  to  the 
program  as  a  result  of  changes  to  the  environment  in  which 
the  program  must  operate.  As  an  example,  it  is  often  quicker 
and  less  expensive  tc  modify  software  rather  than  the  hard¬ 
ware  in  order  to  modify  weapon  systems  to  satisfy  new  threat 
situations. 

Perfective  maintenance  is  the  process  used  to  accommo¬ 
date  recosmendations  for  new  capabilities,  changes,  and 
general  enhancements  reguested  by  the  user  of  system 
programmer. 

Preventive  maintenance  takes  place  when  software  is 
changed  in  order  to  improve  its  future  maintainability.  This 
type  of  maintenance  remains  a  rare  practice  in  software 
engineering. 

Based  upon  a  study  of  487  software  development  organiza¬ 
tions  by  Lientz  and  Swanson,  as  summarized  in  reference  1, 
5055  of  all  maintenance  is  perfective.  Corrective —  and 
adaptive  maintenance  account  for  2*55  and  2555,  respectively. 
All  other  types  of  maintenance  account  for  only  4%. 

B.  TANGIBLE  HAINTEHABCE  COST 

Although  considered  by  many  software  engineers  as  the 
less  glamorous  and  unexciting  phase  of  software  development, 
maintenance  accounts  for  the  majority  of  the  dollars  spent 
throughout  the  software  life  cycle.  The  cost  of  maintenance 
has  shewn  a  dramatic  and  steady  increase  over  the  past  two 
decades.  As  depicted  in  figure  5.1,  one  author  [Ref.  1  :  p. 
326]  estimates  that  maintenance  cost  as  a  percentage  cf  the 
total  software  budget  will  have  grown  from  35-4055  in  1970  to 
70- 8 OX  in  1990. 


Figure  5.1  Maintenance  Cost  as  Percentage  of  Budget 

Although  empirical  data  is  available  to  account  for 
total  software  life-cycle  cost  allocatable  to  maintenance, 
maintenance  costs  are  very  difficult  to  estimate  in  advance. 
It  is  known,  however,  that  maintenance  costs  are  often 
dramatically  underestimated  by  both  industry  and  government 
suring  the  pre-  deployment  phases  of  system  acquisition.  To 
illustrate  this  point,  Boehm  [Ref.  23  :  p.127]  estimated 
that  it  took  $30  to  develop  a  line  of  code  (IOC)  ,  but  the 
cost  per  IOC  skyrocketed  to  $4000  in  the  maintenance  phase. 
Although  $4000  per  IOC  may  seem  unreasonably  high,  it  is  not 
unusual  to  incur  such  high  costs  for  maintaining  mission- 
critical  software  in  EoD  weapon  systems. 

Although  there  is  not  a  set  of  universal  factors  that 
can  be  applied  to  all  software  development  projects  to  accu¬ 
rate  estimate  the  relative  cost  of  program  modification  in 
each  of  its  life  cycle  phases,  figure  5.2  illustrates  the 
exponential  rise  in  maintenance  costs  in  each  of  the  phases. 
[Ref.  24  :  p.14] 
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It  is  apparent  that  there  is  more  potential  for  real¬ 


izing  life  cycle  cost  savings  by  devoting  more  planning 


K  during  the  earlier  phases  in  order  to  minimize  the  reguire- 
jj  menfc  for  maintenance  during  subsequent  phases.  One  of  the 
R  primary  reasons  for  the  high  cost  during  the  later  phases  is 
h  due  tc  the  "domino  effect"  of  changes  that  must  be  proaul- 
|  gaved  throughout  the  entire  system  for  what,  may  seem  at 
|  first  to  be  a  simple  code  modification  reguirement. 


C.  VARIABLES  APFECTISG  HAINTENANCE  COSTS 


As  mentioned  in  the  preceding  section,  an  accurate  esti- 
mate  of  maintenance  costs  for  a  particular  program  is  very 
difficult.  Sommervile  [Ref.  25  :  pp.  193  -1993  has  identi¬ 
fied  five  relatively  unpredictable  factors  that  contribute 
to  the  difficulties  involved  in  deriving  cost  estimates  for 
maintenance.  These  factors  include: 


(5) 


J2&L&S  ££££££££&•  The  better  the 
LIcatlonnSIng  supported  by  software  is  ander- 

iS  .  this  avsf  an  rnrnn  ramontc  n  h  o 


sflol.  the  better  the  systefi  raguiremen ts  can  be 
stated.  The  more  definitive  the  system  requirements 
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It  is  normally  easier  for  the 
or  of  the  program  to  make  changes  than 
programmer  who  must  gain  an  under- 
tne  program  by  studying  its  documenta- 
man  [Ref.  1j  uses  the  term  alien  c§deM 


'programs  that  are  extremely  diffi- 

_  r  d  by  those  that  must  maintain  them. 

Reasons  for  alien  code  include:  (1)  no  current 

member  on  the  maintenance  staff  was  involved  in  the 
development  of  the  program,  (2)  poor  design  and 


programming  profession  has  mads  it  a  rare  occurrence 
for  the  same  individuals  to  develop  and  maintain  a 
pregram  throughout  its  life  cycle. 

Software  is  designed  to  be 
e  hardware  that  will  support. it. 


cp  mpat  ible5^  e  hardware  that  will  support  it. 
Changes. to  the  hardware  configuration  will  likely 
result  in  requirements  for  software  modification. 


D.  INTANGIBLE  MAINTENANCE  COSTS 


Th«  direct  cost  of  maintenance,  although  considerable, 
nay  be  of  secondary  concern  when  compared  with  the  less 
obvious  and  intangible  cost  of  maintenance.  A  quote  by 
Daniel  Mccraken  [Ref.  1]  sunnarizes  one  of  these  intangible 
costs,  the  development  opportunities  that  are  lost  due  to 
the  resources  that  must  be  allocated  to  maintenance  efforts: 

"Backlogs  of  nev  applications  and  major  changes  that 
measure  in  years  are  getting  longer.  As  an  industry,  ve 
can't  keep  up— let  alone  catch  up— with  what  our  users 
want  us  to  do. " 

McCraken  alludes  to  what  Pressman  1  call  a  "maintenance- 
bound"  software  development  organization  which  is  no  longer 
capable  of  producing  new  software  because  all  its  resources 
are  devoted  to  the  maintenance  of  existing  software. 
Pressman  lists  other  intangible  costs  including: 

— Customer  dissatisfaction  due  to  the  untimely  response 
By  the  software  development  organization  to  the  user's 
development  and  taintenance  requests 

—  brought  about  by  latent 
err orB^tntroducea  during  tnd  maintenance  of  software 

—  development  efforts  as  personnel  and  other 
resources  Ire  ,rplIIIe3Trto  wdf K  on  maintenance  tasks 

E.  BUILDING  MAINTAINABLE  SOFTVARE 

Economic  and  efficient  support  of  software  is  best 
achieved  when  its  maintainability  is  integrated  into  the 
total  development  effort  from  day  one.  The  maintainability 
of  software  can  be  quantitatively  measured  based  on  the  ease 
by  which  it  can  be  understood  and  changed  [Ref.  26  :  p.  14]. 

Software  under standability  is  a  function  of  the  design 
and  documentation.  It  is  easy  to  understand  due  to  its 
logical  and  simple  structures,  and  it  is  supported  with 


documentation  that  permits  an  examination  of  the  implementa¬ 
tion  without  losing  an  understanding  for  the  entire  picture. 
Software  changeability,  on  the  other  hand,  is  a  function  of 
the  design  and  implementation.  As  an  example,  implementa¬ 
tion  of  modular  independence  facilitates  changes  to  a 
selected  segment  by  minimizing  the  degenerative  affect  on 
other  segments. 

Building  maintainable  software  is  based  on  the  usage 
of  a  set  of  software  engineering  tools  and  techniques  that 
together  form  a  structured  methodology  for  software  develop¬ 
ment.  As  the  authors  £Bef.  26]  write,  the  principal  elements 
of  this  structured  methodology  include: 


system  proces 


rocess  for  developing  the 
face  requirements  or  the 
ng  a  logical  model  of  the 


f  subdividing 
a  way  that 


the  soft- 
tends  to 


Structured  Programming.  The  discipline  of  imp  lament in 
FEe  gSnfFol  structure  of  software  modules  using 
restrictive  set  of  structures. 


Program  Design  Language  (PPL) .  Language  processors  that 
are  us^d  HTo  a ocUlent  software  designs  in  a  structured 
top-down  manner.” 


Although  there  are  many  other  disciplines  and  concepts  that 
must  also  be  considered  as  part  of  a  complete  structured 
methodology,  such  as  top-down  implementation,  structured 
walk-throughs,  chief  programmers  teams,  and  so  forth,  these 
managerial  disciplines  are  used  primarily  for  the  software 
development  effort.  The  methodologies  underlined  above  will 
have  a  visible  affect  on  the  software  product  long  after  its 
development  is  completed.  A  detailed  description  of  the 
characteristics  of  each  of  these  elements  is  provided  in 
Appendix  C. 
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Although  there  are  many  other  disciplines  and 
concepts  that  must  also  be  considered  as  part  o£  a  complete 
structured  methodology ,  such  as  top-down  implementation, 
structured  walkthroughs, •  chief  programmers  teams,  and  so 
forth,  these  managerial  disciplines  are  used  primarily  for 
the  software  development  effort.  The  methodologies  under¬ 
lined  above  will  have  a  visible  affect  on  the  software 
product  long  after  its  development  is  completed.  A  detailed 
description  of  the  characteristics,  as  provided  in  £Ref.  26] 
of  each  of  these  elements  is  provided  in  Appendix  B.  A  more 
general  discussion  of  each  will  now  be  presented. 

2.  AaaAia&a 


Structured  analysis  is  often  considered  the  starting 
point  in  the  set  of  structured  design  techniques.  The  main 
objective  of  structured  analysis  is  to  build  a  logical  model 
of  the  desired  system.  This  should  be  done  to  the  greatest 
extent  possible  without  premature  consideration  of  physical 
implementation. 

In  its  simplest  form,  the  logical  model  is  a  picto¬ 
rial  representation  with  accompanying  narration  describing 
the  functions,  and  their  interrelationships,  of  the  system 
that  they  comprise.  Examples  of  the  some  of  the  most  popular 
forms  of  these  graphical  representations  include  process  and 
information  flowcharts,  data  flow  diagrams,  hierarchy  chart 
plus  input-  processing-output  chart  (HIPO  charts),  and 
procedure  analysis  charts. 

The  net  result  of  the  this  structured  analysis 
process  should  be  a  logical  model  that  defines  the  complete 
system  which  reflects  all  facets  of  the  system  specification 
and  software  requirement  document.  The  model  should  be  a 
form  of  communicaticn  easily  understood  by  both  technical 
and  nontechnical  personnel,  alike.  Through  the  use  of  this 
model,  the  system  analyst  should  be  to  develop  system 


58 


requirements  without  undue  consideration  of  physical  imple¬ 
mentation  constraints.  On  the  other  hand,  nontechnical  users 
should  readily  be  able  understand  how  the  required  functions 
fit  together  within  the  context  of  the  whole  system. 

3.  Siuisiatsa  cssiai 


Structured  design  is  the  process  of  of  decomposing 
the  software  design  into  hierarchial  modules  in  a  manner 
that  leads  toward  independence  of  modules.  Benefits  of 
structured  design  to  the  development  and  maintenance  of 
software  include  increased  understandability  of  the  system 
and  a  minimization  of  the  cost  inherent  in  modification. 

Nodularity  is  the  key  element  of  structured  design. 
It  allows  for  software  to  be  better  managed.  Large  mono¬ 
lithic  (i.e.,  single  module)  programs  are  often  unintellige- 
able  to  the  reader.  Nodularity  is  based  on  a  "divide  and 
conquer"  concept,  breaking  complex  problems  into  comprehen¬ 
sible  and  manageable  components.  Two  primary  measurements 
of  modularity  are  (1)  cohesion,  and  (2)  coupling. 


functional 
A  module  is 


strength" 
said  to  be 


sign  is  the  "relative 
_er.  i  :  p.  1581  of  a  module. 

ohesive  If  it  .pc-' - “ 

program,  requiring  ■  ___  _  _ 

Srogram  code  external  to  its  boundaries.  In  general, 
eslgn  should  attempt  to  realize  the  highest  degree 
of  module  cohesion. 


performs  a  single  task  within  a 
mg  little  interaction  with  other 


—  Coupling  is  a  measurement  of  the  connectivity  amon< 
other  modules.  It  is  based  on  (1)  the  interface 


complexity  between  modules.  (2)  the  place  at  which 
entry  are  reference  are  made  to  a  module,  and  (3)  the 
type  of  data  that  passes  across  the  interface 
:  pp.  161  -  1621.  The  designer  should  strive 
lowest  degree  of  module  coupling. 


Bef.  1 

or  the 


Clearly,  then,  the  objective  of  structured  design  is 
to  minimize  the  relationships  between  modules  through  the 
maximization  of  the  functional  strength  of  each. 
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4 .  Structured  Programming 


Structured  programming  is  the  discipline  of  imple¬ 
menting  nodule  functionality  through  the  use  of  a  United 
set  of  progressing  structures. 

Structure  progressing  uses  top-down  design  by 
starting  with  the  top-level  nodule  and  deconposing  it  into 
lover-level  nodules  that  it  will  call  upon.  This  decomposi- 
tion  process  repeated  as  often  as  necessary  until  the 
bottom- level  nodules  are  defined.  At  this  bottom  level, 
modules  make  use  of  built  in  operators  and  functions;  they 
do  not  call  on  any  other  nodule.  Each  nodule  is  separately 
coded  using  the  basic  set  of  program  instructions.  An  objec¬ 
tive  of  structured  programming  is  to  male  the  design  natch 
the  structure  of  the  program. 

Any  program,  regardless  of  its  size  and  complexity, 
can  be  designed  using  three  basic  programming  structures. 
The  use  of  this  set  of  programming  structures  reduces  the 
procedural  design  of  the  program  to  a  small  number  of 
predictable  operations,  greatly  facilitating  the  development 
and  maintenance  of  software.  These  structures  are  illus¬ 
trated  in  Figure  4.3. 

5-  J2££iS£  1AM&3SS 

Program  Design  Languages  (PM.)  are  language  (text)  proces¬ 
sors  that  are  used  to  document  software  designs  in  a  struc¬ 
tured  top-  down  fashion.  The  goal  of  a  PDL  is  to  replace  or 
support  traditional  forms  of  documentation  of  program 
design. 

The  primary  benefits  of  a  PDL  are:  (1)  the  documen¬ 
tation  that  it  produces  is  normally  easier  to  read  and 
understand  than  flow  charts,  and  (2)  the  documentation  is 
always  easier  to  change  than  are  flow  charts.  Both  of  these 
advantages  are  essential  during  maintenance  activities. 


f. 


PASTING  COMMENTS 


The  maintainability  cf  software  is  inseparable  from  the 
degree  of  quality  that  was  built  in  prior  to  the  maintenance 
phase.  Sound  software  engineering  practices,  coupled  with 
the  iap lament at ion  of  managerial  controls  in  maintenance 
activities,  offer  the  key  to  improved  productivity  and  the 
reduction  costs  associated  with  maintenance  activities. 
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A.  IITRODOCTIOH 

In  1980,  it  was  estimated  that  DoD  spends  about  $7 
s  year  on  software  [Ref.  28  •  p.  3]«  This  amount 
has  been  steadily  increasing  as  DoD  becomes  increasingly 
dependent  on  larger  and  more  complex  software  products  to 
support  this  generation  of  sophisticated  weapon  systems.  The 
upward-spiralling  trend  in  the  cost  of  DoD  software  has 
naturally  become  an  area  of  great  concern  to  officials  in 
both  military  and  government.  This  concern  has  led  to  a 
number  of  management  initiatives  in  DoD,  several  of  which 
sUa*  be  discussed  in  this  chapter.  At  the  heart  of  these 
initiatives  is  the  standardization  of  computer  technology 
and  software.  Standardization  Is  seen  a  means  for  reducing 
costs  associated  with  the  development,  operations,  and 
support  of  DoD  computer  systems. 


B.  SPECIFIC  IHITIATIVES 


In  her  article  [Bef.  29  j  pp.  37  -  47  J  Becker  describes 
three  distinct,  but  interrelated,  initiatives  that  reflect 
the  DoD  standardization  effort.  These  initiatives  are  as 
follows: 


(1)  !(MCFfriny,S  devel°Pnent  of  a  Military  Computer  Family 

t2‘  (H0L, 
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software.  -It  can  also  bl  defined  ai  the  SSSS- 
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(3)  A  proposed  DoE  instruction  set  architecture®  (ISA) 
standard  (Draft  DoD  instruction  5000. 5X). 

The  first  two  of  these  initiatives  will  be  summarized 
from  Becker’s  article.  In  addition,  this  section  will 
address  standardization  efforts  by  the  Joint  logistic 
Commander’s  (JLC’s)  panel  of  Computer  Resource  Management 
(CRM) . 

1.  £2A£JlJS£  Zl&ilx 

The  distinguishing  characteristic  in  the  Military 
Computer  Family  (MCF)  initiative  is  a  common  instruction  set 
architecture.  The  efforts  to  develop  MCF  began  in  the 
mid- 1 970 ’s  with  an  intensive  review  of  the  Army’s  mission- 
critical  software.  The  Army  first  attempted  to  obtain  an 
existing  ISA  through  a  licensing  agreement  from  the  commer¬ 
cial  sector.  Following  an  extensive  evaluation  of  this  first 
step,  the  Army  concluded  a  licensing-agreement  approach  was 
severely  limited  for  a  number  of  reasons:  [Ref.  29  :  p.  41] 

(1)  The  adoption  of  a  commercially-available  ISA  was 
perceived  as  placing  unnecessary  technical  and 
administrative  restrictions  both  on  the  partici¬ 
pating  vendor  and  the  Army. 

(2)  The  protection  and  sqope  of  a  commercial  ISA  were 
perceived  as  a  potential  hindrance  to  the  wide  usage 
being  considered  by  the  Army. 

(3)  Adopting  a  single  firm’s  ISA  was  viewed  being  of 
unfair  advantage  to  one  company  or  a  selected 
segment  of  the  industry,  thus  greatly  restricting 
competition. 

As  an  alternative,  the  Army  engaged  the  services  of  Carnegie 
Mellon  University  to  develop  an  ISA,  which  became  known  as 
’’Nebula”  ISA  and  designated  by  MIL-STD-182A.  Nebula  has  been 
rated  as  both  an  effective  and  advanced  ISA.  Under  a  memo¬ 
randum  of  agreement,  the  Army  and  the  Air  Force  have  worked 
jointly  to  develop  and  control  the  Nebula  program. 

Using  Nebula  as  the  keystone,  the  Army  has  engaged 
in  a  multiphased  competitive-procurement  process  to  develop 
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a  prototype  computer  model  which  will  be  at  the  heart  of  the 
MCF.  Although  a  number  of  competing  companies  will  be 
involved  the  the  pre-production  phases  of  this  development 
effort,  only  one  company  will  be  selected  to  enter  the 
production  phase.  The  number  of  units  acquired  during  the 
production  phase  will  be  based  on  unit  cost  as  stipulated  in 
a  requirement  agreement  that  was  used  as  a  criteria  in  the 
final  competition. 

Technological  infusion  is  a  major  consideration  of 
the  MCF  strategy,  ensuring  that  the  MCF  has  current  technol¬ 
ogies  included  in  the  mission-critical  systems  that  are 
fielded.  The  Army  hopes  the  the  MCF  program  will  result  in 
improved  survivabilty  and  logistics,  as  well  as  a  reduction 
of  life  cycle  costs  of  the  MCF  systems. 

2.  Ada 

About  the  same  time  that  the  Army  began  its  MCF 
program,  the  Department  of  Defense  recognized  the  need  for  a 
state-of-the-art  program  for  embedded  computer  applications. 
In  the  mid-1970f s,  DoD  was  spending  about  $3  billion  a  year 
on  software,  with  the  greatest  portion  going  for  embedded 
systems  [Ref.  30  s  p.  268].  After  concluding  that  the 
existing  programming  languages  were  inadequate  for  satis¬ 
fying  future  software  development  needs,  DoD  set  up  the 
Higher-Order  Language  Working  Group  (HOLWG)  to  investigate 
the  development  of  a  new  programming  language.  During  the 
four  year  period,  1975  to  1979,  HOLWG  published  a  series  of 
mandatory  specifications  for  the  new  language.  Each  set  of 
specifications  were  more  detailed  than  the  preceding  set,  as 
implied  by  their  names:  [2ef.  30  :  p.  269] 

In  1977,  HOLWG  studied  26  languages,  none  of  which 
was  able  to  meet  the  required  specifications.  A  competitive 
language  design  effort  was  initiated  1977.  By  1979,  the  16 
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original  propositions  submitted  by  industry  were  reduced  to 
one.  The  winning  language  was  designed  by  CII-Honey-Eull, 
and  was  re-named  "Ada."7  [Ref.  30  :  p.  269] 

The  Ada  Joint  Program  Office,  under  the  Deputy  Under 
Secretary  of  Defense  (Research  and  Advanced  Technology) ,  is 
responsible  for  the  management  and  implementation  of  all 
Ada-related  activities. 

Ada  is  not  without  problems  and  limitations. 
Designed  to  facilitate  a  wide  range  of  applications,  Ada  is 
an  extre&ely  complex  and  large  language.  Using  context-free 
grammar  tokens  as  a  measurement,  Ada  is  estimated  at  1600 
tokens  long,  Pascal  at  500,  and  Algol-60  at  600.  The  devel¬ 
opment  of  Ada  has  already  been  subjected  to  many  of  the  same 
criticisms  received  by  IBM  during  their  effort  to  design 
FORTRAN  VI.  The  resulting  language,  which  incorporated 
features  from  FORTRAN,  Algol,  and  COBOL  was  unrecognizable 
as  FORTRAN  and  was  subsequently  renamed  PL/I.  PL/I  repre¬ 
sents  the  classic  "Swiss  Army  knife"  approach  to  software 
design  in  which  all  conceivable  features  that  a  user  might 
need  are  built  into  a  single  language.  The  final  product 
being  too  large  and  complicated  for  most  programmers  to 


7Ada  is  a  trademark  of  the  Department  of  Defense,  named 
:or  Augusta  Ada  Lovelace,  the  world's  first  programmer,  and 
laughter  of  Lord  Byron. 


master  [Ref.  30:  p.  182].  As  with  PL/I,  the  size  of  Ada  nay 
lead  to  similar  problems  as  well  as  inefficiencies  in  real- 
time  application. 

Provisions  and  exceptions  will  have  to  be  made  by 
the  DoD  for  existing  computer  systems  whose  software  is 
written  in  other  languages  besides  Ada  and  where  conversions 
to  the  Ada  language  may  not  always  be  possible  or  feasible. 
However,  it  will  be  expected  that  Ada  will  be  applied  where 
possible,  and  deviations  to  this  requirement  discouraged. 
Full  ivplementation  of  Ada  is  bound  to  take  some  time  since 
the  language,  itself,  is  still  in  a  state  of  transition  and 
because  of  the  huge  investment  DoJ)  presently  has  in  programs 
written  in  other  languages. 

It  typically  takes  the  better  part  of  a  decade  for  a 
new  language  to  become  fully  established,  but  Ada’s  initial 
acceptance  by  the  commercial  sector  has  been  good.  Convinced 
that  the  use  of  Ada  will  increase  "flexibility  and  aid  in 
the  greater  utility  of  its  software  packages,"  [Ref.  29  :  p. 
43]  IBS  has  begun  to  implement  a  version  of  Ada.  Another 
indication  of  the  general  acceptance  of  Ada  Is  the  fact  that 
the  Ada  language  is  in  its  final  stages  for  consideration  by 
the  American  National  Standards  Institute. 

3.  Jgint  iasisites  CSW&dSES  £<2£&£ho£ 

In  April,  1979  the  Computer  Software  Management 
(CSM)  subgroup  of  the  Joint  Logistic  Commanders  (JLC)  Joint 
Policy  Coordinating  Group  on  Computer  Resources  Management 
(JPCG-CRM),  sponsored  a  workshop  at  the  Naval  Postgraduate 
School  in  Monterey,  California — appropriately  entitled 
Monterey  I.  The  purpose  of  the  workshop  was  to  review  the 
services’  software  acquisition  guidelines,  management  poli¬ 
cies  and  procedures,,  and  standardization  efforts  to  see  if 
there  was  a  basis  for  the  adoption  of  joint-service  guidance 
in  these  areas.  Monterey  I  concluded  with  the  recommendation 
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that  the  services  should  adopt  common  software  policies, 
development  standards,  and  documentation  standards  instead 
of  continuing  with  each  of  the  service’s  unique  and  often- 
time  redundant  efforts  pertinent  to  these  areas.  The  advan¬ 
tages  could  be  attributed  to  the  adoption  of  joint-services 
standards:  1)  economies,  and  2)  the  best  methods  of  each 

service  could  be  adopted  for  use  by  all  [Ref.  31  :  p.192]. 

Other  findings  of  the  workshop  included:  [Ref.  32  : 
pp.  2-1  -  2-9] 

(1)  No  genera], 
ware 


policy  exists  for  defining  a  common  soft- 
acguisitlon  framework  for  the  joint  services. 


(2)  A. number  of  dive 
within  DoD  cover 
acquisition  and 


rse  regulations  and  standards  exist 
ing  the  various  aspects  or  software 
software  documentation. 


(3) 


MII-S-52779,  "  Software. Quality  Assurance  Proqram 
Requirements,'’  has  been  widely  used  since  1974,  ‘and 
has  become  an  official  joint  services  standard.  The 
application  of  this  standard  has  been  met  with 
varying  degrees  of  success.  Its  application  has  been 
considered  unacceptable  due  to  the  imposition  ◦£ 
additional  schedule  and  budget  requirements. 
Furthermore,  DoD  plant  representatives  and  DCASR 
personnel  have  founa.it  most  difficult  difficult  to 
use  in  the  evaluation  and  monitoring  of  software 
development  contractors. 


(4) 


f  recognized  software  acceptance  criteria,  a 
f  DoD  standardization,  an 
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ack  o  _ , _ 

cal  data  upon  which  to 
procedures. 


ck/ lauCfe  un.Eij.ai  a 

d  a  lack  pf  h^stor- 
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Recommendations  included  the  following: 

(1)  Develop  a  general  policy  framework  for  the  joint 
services  to  address  the  entire  software  life  cycle. 

(2)  Develop  a  unified  set  of  acquisition  and  development 
standards  for  tri-service  service  application. 

Develop  a  comprehensive  set  of  data  item  descrip¬ 
tions  (DID '  s) ,  subsets  which  could  be  used  for  and 
software  contract. 

quality 


(3) 


(h)  Generate  a  DID  for  contractor's  software 
assurance  plan  as  a  joint  service  did. 


(5)  Define  and  develop  software  acceptance  policy, 
- v -  *  — iteria  for  the  acquisition  hi. 


II? 


ense  system  software. 


The  Monterey  I  workshop  concluded  with  the  CSM 
developing  a  plan  of  actions  and  milestones  for  the 
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implementation  of  the  recommendations  listed  above,  which 
were  subsequently  approved  by  the  JLC»s. 

Since  receiving  the  go-ahead  from  the  JLC’s,  signif¬ 
icant  process  has  been  made  in  carrying  out  the  implemeta- 
tion  plan  £fief.  33  :  pp„  21  -  22 }.  The  basis  for  this 
effort  was  centered  around  the  definition  of  the  software 
development  life  cycle,  with  the  data  item  descriptions  and 
standards  integrated  into  the  appropriate  phases  of  the  life 
cycle,  Twenty-five  basic  DID* a,  defined  for  this  purpose, 
replaced  a  total  off  over  200  previous  ones.  This  has  signif¬ 
icantly  streamlined  the  documentation  requirements  required 
for  a  given  acquisition. 

Ihs  optional  practice  of  conducting  a  preliminary 
design  review  has  now  b«er:  formalized,  thus  focusing  mere 
attention  on  the  requirement  definition  area  of  the  develop¬ 
ment  effort.  This  should  lessen  the  problems  associated  with 
late  requirements  identification  and  configuration  control. 

A  new  Software  Development  Standard  (SDS)  has  been 
written  using  HI1-STE-1679  (Wavy)  as  one  of  its  basic1  docu¬ 
ments.  The  SOS  document  is  at  the  heart  of  the  development 
effort  since  it  defines  the  contractors  responsibilities. 
It  emphasizes  sound  software  engineering  practices,  such  as 
top-down  design,  structured  programming,  and  modulization. 
Other  changes  to  existing  standards  are  being  implemented  in 
areas  such  as  Configuration  Control,  Equipment  and  Computer 
Programs,  Specification  Practices,  and  Technical  Reviews  and 
Audits  for  Systems,  Equipments  and  Ccmputer  Programs.  Two 
documents  have  been  prepared  in  the  area  of  Quality 
Assurance:  (1)  the  Software  Quality  Assurance  Measurement 
(SQAM)  document,  specifying  required  measurements,  and  (2) 
The  Software  Quality  Policy,  detailing  the  policies 
governing  quality  assurance  and  which  will  liJcely  replace 
the  current  Software  Quality  Assurance  Program  Requirements, 
MIL-STD- 52779. 
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A.  OVERVIEW  OF  STARS 

The  scope  of  the  STARS  (Software  Technology  for 
Adaptable  ,  Reliable  Systems)  program  is  perhaps  the 
broadest  and  farsighted-  software  initiative  ever  undertaken. 
It  addresses  almost  every  socioeconomic,  technological, 
political,  and  psychological  aspect  associated  with  the 
problems  of  software  development  and  maintenance  for  major 
military  systems.  STARS  is  deliberately  structured  [Ref.  34: 
p.  14]  to  facilitate  and  encourage  the  rapid  transition  of 
new  technology  into  practice.  STARS  is  intented  to  be  an 
impetus  for  a  cooperative  environment  among  the  govern¬ 
mental,  commercial,  and  academic  sectors  of  0.  S.  society  in 
which  technology  transfers  will  freely  occur,  and  through 
which  highly  automated  and  efficient  software  support  envi¬ 
ronments  will  be  developed. 

The  DoD  has  a  continuing  interest  in  the  development  of 
computer  technology.  It  is  in  the  best  interest  of  the  DoD 
and  the  country  to  maintain  a  front-runner  position  in 
computer  technology.  To  this  end,  the  DoD  has  established 
the  VHSIC  and  Ada  programs.  The  VHSIC  program  (very  high 
speed  integrated  circuit)  aims  "to  gain  and  maintain  a  qual¬ 
itative  lead  over  potential  adversaries  by  providing  afford¬ 
able  complex  military  functions  in  extremely  small, 
ultrareliable  packages  suitable  for  operation  in  severe 
military  environments."  [Ref.  34  :  p.  16]  The  Ada  program 
entails  the  development  of  a  high-order  language  for  mission 
critical  computer  systems.  While  both  programs  have  made 
strides  in  maintaining  American  superiority  in  computer 
technology,  a  software  initiative  is  being  launched  to 


complement  them.  STABS  aims  to  develop  the  systems  and  soft¬ 
ware  techniques  through  which  this  superiority  can  be  main¬ 
tained. 

DoD  has  found  that  software  changes  are  easier  and  less 
costly  than  changes  to  physical  components  of  military 
systems.  While  this  can  be  a  major  military  advantage,  the 
needed  technology  to  make  these  software  changes  is  not 
always  available.  The  software  requirements  are  ahead  of  the 
systems  needed'  to  institute  them.  Other  problems  involved 
in  the  software  dilemma  besides  inadequate  technology 
include  inappropriate  acquisition  and  management  practices 
and  a  serious  shortage  of  skilled  people.  Controlling  and 
managing  software  projects  is  a  major  concern  of  DoD.  Costs 
for  software  are  becoming  the  major  cost  factor  on  many 
systems  projects.  These  costs  must  be  predicted  and 
controlled.  The  supply  of  trained  professionals  is  inade¬ 
quate.  Currently  the  gap  ‘’between  demand  and  supply  has 
been  estimated  in  terms  of  50,000  to  100,000  software 
professionals,  and  if  nothing  is  done,  this  gap  could  become 
860,000  to  1,000,000  software  professionals  by  1990." 
[Hef.  35  ;  pp.  52  -  53] 

STABS  looks  at  addressing  the  technology,  management, 
acquisition  and  personnel  problems  in  two  ways  which  will 
parallel  each  other.  The  long  range  approach  is  to  "leapfrog 
current  technology  and  completely  change  the  view  of  the 
software  process",  as  quoted  from  reference  &STAB3 . This 
approach  is  deemed  necessary  since  current  methodologies  do 
not  appear  to  be  able  to  satisfy  fully  the  future  require¬ 
ments.  Opportunities  on  the  horizon  which  are  to  be  evalu¬ 
ated  include:  expert  systems,  very  high  level  languages, 
functional  programming  and  program  generation  systems. 
While  successful  fulfillment  of  these  opportunities  will 
enhance  the  software  environment,  they  will  take  time  to 
develop.  The  second  approach  is  to  "bridge  the  gap"  until 


the  more  futuristic  opportunities  can  he  developed.  The 
second  approach  entails  an  evolutionary  strategy  of  building 
upon  the  existing  systems,  improving  them,  adding  tech¬ 
niques,  refining  models,  and  training  people  along  tradi¬ 
tional  lines  of  software  development.  As  stated  by  Boehm  and 
Stan  dish,  this  approach  is  necessary  to  "combat  the  software 
supply-demand  gap".  By  learning  how  to  manage  skillfully  the 
large  number  of  variables  involved  in  software  projects  and 
integrating  the  key  concepts  existing  in  the  software  envi¬ 
ronment,  managers  can  utilize  their  resources  needed  for 
effective  software  development.  Completeness  and  integration 
are  the  key  concepts  of  this  second  approach.  [Bef.  36  : 
pp.  30-37] 

B.  OBJECTIVES 

The  primary  goal  of  the  STABS  program  is  to  "improve 
productivity  while  achieving  greater  system  reliability  and 
adaptability.”  [Bef.  35  :  p.  56]  Do D  software  in  many 
instances  is  of  vital- importance  in  providing  life-essential 
functions,  such  as  computerized  flight  controls.  Due  to 
this  stringent  requirement,  reliability  is  of  utmost  impor¬ 
tance.  The  software  must  be  easily  adapted  to  changes  in 
mission  requirements.  A  third  key  element  is  that  of  afford¬ 
ability.  As  stated  earlier,  cost  is  an  important  factor  and 
becoming  more  sc  as  more  systems  are  software  dependent. 
These  three  items,  reliability,  adaptability  and  afford¬ 
ability  form  the  backbone  behind  the  goal  of  STABS.  As 
stated  by  the  initiating  task  force  of  STABS,  "We  need  to 
improve  the  state  of  practice  throughout  the  DoD  community 
so  that  we  can  provide  development  and  in-service  support 
that  is  faster,  less  expensive,  and  more  predictable  and 
results  in  software  that  is  more  powerful,  reliable,  and 
adaptable."  [Bef.  35]  Based  on  this  goal  of  an  improved 


software  development  environment,  three  basic  objectives  are 
established  for  STABS:  1)  expand  the  level  and  base  of 
expertise  in  both  the  government  and  private  sector;  2) 
improve  management  methods,  application-  independent- 
technical,  and  application-specific  tools;  and  3)  increase 
the  use  of  tools  by  adding  incentives,  improvements  to 
useability  and  added  automation  and  integration.  For  each  of 
the  objectives,  a  task  area  has  been  established  with 
specific  plans  of  pursuing  the  objectives.  This  paper  will 
discuss  the  task  areas  of  effectiveness  measurements, 
project  management  and  acquisitions. 


"The  STARS  program  will  be  carried 
context  of  a  variety  of  on-going  ana  p 
It  will  establish  a  basis  for  cl 


out  within  the 
lanned  activities. 
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The  progran  will  be  instituted  in  a  7-8  year  period. 
Beginning  in  FY84  with  the  preparation  stage,  the  following 
three  consecutive  two  year  periods  include  the  consolida¬ 
tion,  enhancement,  and  transition  stages.  The  consolidation 
stage  focuses  on  putting  current  technology  into  practice. 
This  includes  fully  utilizing  the  management  tools,  auto¬ 
mated  software  tools  and  implementing  the  latest  procurement 
strategies.  The  second  stage  focuses  on  enhancing  the  envi¬ 
ronment  established  in  the  first  stage.  This  is  an  evolu¬ 
tionary  process  of  refinement  and  improvement.  The  final 
stage  will  institute  a  fully  funded  STABS  program.  Also  in 
this  transitional  stage  any  HSD  developments  which  have 
reached  fruition  can  be  transitioned  into  utilization  in  the 
software  environment. 


C.  0HGAHI2ATI0H 


The  program  ia  vertically  managed  under  the  Under 
Secretary  BSD.  A  joint  Service  team  under  the  Under 
Secretary  will  provide  the  initial  planning  and  coordinating 
o£  the  program.  Contractors  will  assist  as  reguired  and 
selected  as  appropriate  by  various  i>oD  agencies.  To  aid  in 
the  government/contractor/academia  interface,  a  free 
exchange  software  engineering  institute  will  be  established 
to  encourage  technology  transfer  and  thus  promote  a  common¬ 
alty  of  goals  and  interest.  The  technology  transfer  will  ba 
further  enhanced  by  various  DoD  agencies'  BSD  centers 
concentrating  on  their  particular  area  of  interest  rather 
than  attempting  to  cover  the  full  spectrum  of  software  engi¬ 
neering.  Also  each  £oD  agency  will  be  assigned  responsi¬ 
bility  of  supporting  various  technology  areas.  Funding  for 
the  program  is  proposed  to  rise  from  the  $60M  level  in  FY84 
to  the  $100M  level  in  FY86  (constant  FY84  dollars) . 

0.  EFFECTIVE  MEASUREMENTS 

Measurement  of  key  elements  in  a  system  allow  one  to 
understanding  the  system  process  and  therefore  control  the 
process  [Bef.  38  :  pp.  47  -  53].  Maintaining  control  and 
predicting  outcomes  in  software  development  projects  is  a 
major  advance  in  software  technology.  Practical  benefits  of 
being  able  to  achieve  effective  measurements  include:  1) 
provides  a  description  of  the  software  environment;  2) 
allows  possible  prediction  of  project  parameters  such  as 
cost,  delivery  time,  constraints,  and  guality;  3)  permitting 
the  expression  of  reguirements  and  goals  quantitatively;  4) 
ability  to  track  progress  and  provide  feedback;  and  5) 
providing  a  means  of  analyzing  costs  and  benefits.  While 
these  benefits  are  great,  obtaining  the  ability  to  have 
reliable  measurements  is  a  task  unto  itself. 
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Two  areas  needing  effective  measurement  are  software 
performance  and  user  performance.  Software  performance 
.becomes  more  important  as  software  plays  a  larger  role  in 
the  overall  system.  Software  systems  must  be  able  to  inter¬ 
face  and  effectively  synchronize  to  function  properly. 
Performance  of  users  has  an  impact  on  the  cost  and  time 
required  to  produce  systems.  Studies  have  shown  that  devel¬ 
oping  reliable  models  to  predict  such  performance  is  near  to 
impossible. 

STABS  intends  to  institute  a  uniform  method  of 
approaching  the  measurement  task.  In  keeping  with  the 
overall  goal  of  STARS,  an  environment  conducive  of  model  and 
metric  development  will  be  evolved.  In  general  terms,  the 
development  and  refinement  of  existing  models  will  continue. 
More  data  will  be  gathered  and  the  iterative  process  of 
hypothesis  testing  will  continue.  There  will  be  a  widespread 
emphasis  on  using  measurement  tools  and  models.  Manual  as 
well  as  automated  tools  will  be  made  standard  as  much  as 
possible.  With  an  increasing  data  base,  baselines  will  be 
defined  and  maintained.  These  baselines  will  include  size, 
effort,  reliability,  and  the  use  of  methods  and  tools.  All 
in  all  the  benefits  of  the  measurements  will  be  to  allow  the 
assessing  of  methods  and  tools  in  order  to  get  the  most 
product  from  the  least  amount  of  resource  expenditure. 

E.  PROJECT  MAHAGEHEBT 


"The 
area 
earl 
co 
ana  pro 


objectives  of  the  project  management  task 
res  "1)  enhance  the  buyer  manager's  capability  £ 
y  project  planning:  2)  provide  a  better  means  o 

municating  and  coordinating  between  and  within  buyer 
ducer  organizations;  3)  furnishing  tools  to  aid 
managers  in  identifying  and  correcting  problems  before 
they  affect  schedule  or  functional  capability;  and  4) 
increase  the  availability  of  software  engineers  educated 
in  the  principles  cf  project  management."  [Ref.  39  :  p. 
57  ] 
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Most  software  system  development  projects  involve  the  DoD 
and  a  contractor  with  the  DoD  component  being  the  buyer  and 
the  contractor  being  the  producer.  Early  project  planning 
performed  by  DoD  project  managers  is  often  lacking.  Many 
projects  reach  the  award  stage  before  proper  planning  has 
taken  place  in  the  areas  of  mission  analysis,  requirements 
definition,  scheduling  and  cost  identification.  This  causes 
problems  of  unspecified  work  statements  and  misguidance  of 
contractors  in  the  early  contract  period.  The  bottom  line  is 
that  poor  planning  ccsts  money.  STARS  intends  to  overcome 
this  through  general  guidelines  in  the  pre-award  contract 
phase , 

The  second  objective  deals  with  communication  between 
the  contractor  and  the  government  and  the  overall 
contracting  process.  Communications  are  intended  tc  be 
improved  through  better  documentation  and  the  building  of 
closer  working  relations  between  the  contractor  and  the 
government.  The  contracting  process  will  be  addressed 
through  the  establishment  of  a  software  acquisition  panel. 
Th9  panel,  made  up  of  various  service  representatives 
including  STARS  and  input  from  industry,  will  recommend 
appropriate  acquisition  policies,  contract  incentive  mecha¬ 
nisms,  and  make  recommendation  and  promote  changes  to  the 
software  systems  acquisition  process. 

The  third  objective  is  to  equip  the  manager  with  a  stan¬ 
dard  "tool  kit"  consisting  of  management  tools  which  will 
allow  identification  of  problems  before  they  can  impact 
greatly  on  the  project.  This  tool  kit  should  also  be  avail¬ 
able  to  the  contractor  so  that  communication  will  be  along 
the  same  lines.  Examples  of  tools  are:  data  base  managers, 
word  processing,  telecommunications,  graphics,  spreadsheets, 
schedule  generator,  cost  estimation  and  general  reporting 
systems.  The  aim  of  the  tools  is  to  automate  the  tracking  of 
the  project. 


The  final  objective  is  tnat  of  educating  the  project 
managers  into  tho  proper  management  perspective.  This  calls 
for  the  development  of  standard  job  descriptions  followed  by 
training  in  the  areas  of  project  management.  This  objective 
is  important  since  most  individuals  involved  in  project 
management  of  software  systems  were  or  are  software  profes¬ 
sional  and  not  management  professionals. 

F.  IMPROVING  PJSRSOVm  RESOURCES 

Overall,  the  demand  for  software  is  increasing  at  12% 
per  year,  *hil©  the  supply  of  software-producing  personnel 
is  increasing  at  an  annual  rate  of  only  4  percent. 
[Ref.  40:  p.  31]  If  this  trend  continues,  the  shortage  of 
software-producing  personnel  will  increase  tenfold  tc  an 
estimated  shortage  just  under  one  million  software  profes¬ 
sionals  by  the  year  1990.  Each  of  the  services  have  already 
reported  shortages  cf  qualified  software  personnel  and 
predict  that  these  shortages  will  become  critical  by  the 
late  1980's.  [Ref.  35:  p.  53 j  Another  area  of  concern  is 
maintaining  the  skill  levels  of  present  software  personnel 
abreast  of  the  skill  level  demanded  by  rapidly  changing 
technology. 

The  task  objective  to  improve  personnel  resources  is 
based  on  two  fundamental  premises:  (1)  increasing  the  level 
of  expertise,  and  (2)  expanding  the  base  of  expertise  avail¬ 
able  to  DoD.  The  strategy  and  major  subtasks  for  achieving 
this  objective  is  presented  in  detail  in  the  article  by 
orglesby  and  Urban  [Bef.  41  :  pp.  65  -  70]  and  will  now  be 
highlighted. 

1-  l&Z  £2£J1*&USA  &§£££€££££ 

This  major  subtask  is  designed  to  assess  the  human 
resource  issues  of  the  availability,  the  utilization  and  the 
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future  requirements  of  software-related  skills,  only  through 
these  assessments  can  skill  requirements  for  software- 
related  skills  be  determined.  Quantitative  measurements 
based  on  educational  units  and/or  task  period  performance 
would  then  be  used  to  for  qualification  and  classification 
of  employment  and  career  development  of  software 
professionals. 

2.  &&£  laxatives 

Once  the  key  population  assessment  is  completed  and 
skill  requirements  known,  career  structures  (career  ladders) 
can  be  developed  and  put  into  place  for  each  of  the  occupa¬ 
tional  subspecialties  within  the  software-development  field. 

3 .  jx charge  P£ogi^ms 

This  subtask  is  structured  to  increase  the  number  of 
software  personnel  exchanges  for  prescribed  periods  among 
government,  industry,  and  academia.  Regulations  are  already 
in  place  permitting  personnel  exchanges  between  the  services 
and  between  OoD  and  state  organizations.  These  established 
exchange  programs  are  to  be  better  publicized  and  supported. 
Exchange  programs  will  be  initiated  with  industry,  DoD  and 
academia.  These  programs  offer  an  excellent  medium  for  tech¬ 
nology  transfer,  training,  and  a  better  understanding  of  the 
problems  associated  with  a  counterpart  community,  be  it 
inside  or  outside  of  CoD. 


4.  Qtfreir  Educational  Subtasks 


Other  educational  subtasks  contemplated  under  STARS 
to  improve  human  resources  include:  (1)  academic  programs 
that  will  encourage  the  development  or  enlargement  of  soft¬ 
ware  engineering  programs  in  colleges  and  universities,  (2) 
training  programs  utilizing  governmental  or  nongovernmental 
programs  to  advance  the  educational  technology  in  software 


engineering  with  efforts  oriented  toward  Ada  technology,  and 
(3)  learning  aids  that  focus  on  automated  instructional 
systems  and  knowledge-based  tutorial  systems. 

G.  IMPROVING  PROCESSING  TECHNOLOGY 

The  second  approach  taken  by  STARS  to  help  develop  a 
software  support  environment  is  through  the  improvement  of 
processing  technologies.  Processing  technology  includes  the 
"techniques,  methods,  practices,  and  tools  supporting  soft¬ 
ware  over  its  complete  life  cycle".  [Ref.  37  :  p.  22] 

One  way  in  which  this  objective  can  be  met  is  through 
improved  application-independent  technical  tools.  These  are 
tools  that  support  projects  of  all  types,  regardless  of 
application.  Examples  of  application-independent  tools 
include  operating  systems,  linkers,  loaders,  compilers,  and 
programming  languages.  An  example  of  the  latter  is  Ada, 
which  is  the  cornerstone  of  current  efforts  directed  toward 
the  development  of  the  Ada  Programming  Support  Environment 
(APSE).  The  long-term  objective  of  APSE  is  to  provide  a 
common  high-order  language  through  which  programming  support 
environment  tools  can  be  interfaced.  However,  for  the  short¬ 
term  it  is  necessary  for  APSE  to  accommodate  the  multilin¬ 
gual  inheritance  of  DoD’s  diverse,  programming-support  tool 
inventory.  [Ref.  42  :  p.  15] 

A  second  way  in  which  this  objective  can  be  achieved  is 
through  improved  application-dependent  technical  methods  and 
tools.  [Ref.  34]  Examples  of  this  category  of  tools  include 
Very  High  Level  Languages  { VHLL)  ,  libraries,  test  drivers, 
and  simulators. 

Mid—  to  long-term  objectives  of  these  application- 
specific  task  areas  involve  the  use  of  emerging  technology, 
such  as  VHLLs,  Knowledge-based  systems,  and  program  genera¬ 
tors.  The  short—  to  near-term  objectives  (next  seven  years) 
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of  this  task  are  are  centered  around  the  software 
"reusability”  problem  in  which  software  for  each  new  system 
has  been  developed  in  total,  from-  the- ground-up,  as  though 
it  is  the  first  and  last  system  of  its  kind.  Future  efforts 
will  be  directed  toward  the  development  of  Ada- based 
reusable  software.  Reusable  software  is  hardly  a  new  idea, 
but  past  attempts  to  create  sets  of  reusable  software  have 
failed  for  lack  of  guality  control.  To  overcome  similar 
problems,  DoD*s  software  must  be  developed  vith  the 
following  characteristics:  [Ref.  37  :  p.  79] 


frecise  statements  and  validations  of  module  func- 
ions  and  interfaces. 


—  generalized  performance  functions  to  increase  scope 
of  application. 

—  use  of  high  programming  standards  and  widely-accepted 
programming  methodologies. 


—  robust  behavior.  Not  only  must  software  be  reusable, 
reusable  software  must  also  be  accessible  by  software 
developers.  Techniques  for  cataloging  and  ware¬ 
housing  reusable  software  must  also  be  implemented. 
Current  data  base  management  techniques  for  the 
query,  management,  and  retrieval  are  considered 
appropriate  for  this  application.  [Ref.  43  :  p.  18] 


H.  INCREASING  UJE  OF  PROCESSING  TECHNOLOGIES 

Improved  processing  technology  for  software  development 
can  only  make  a  difference  if  people  use  this  improved  tech¬ 
nology.  Another  objective  of  the  STARS  program  is  to 
increase  the  appropriate  use  of  these  technologies.  Two  of 
the  subtask  area  in  supporting  this  objective  are  (1) 
improve  business  practices,  and  (2)  improve  tool  usability. 

IJLE£2J£S  ££&!£&» 

This  subtask  is  aimed  at  changing  current  DoD  regu¬ 
lations  in  order  to  facilitate  the  acquisition  of  software. 
Another  goal  of  this  subtask  is  to  utilize  financial  incen¬ 
tive  schemes  to  encourage  capital  investment  by  industry 


directs  at  the  coordinated  pursuit  of  new  technology  devel¬ 
opment. 

2.  Sssl  flaaiiuiz 

This  sub task  focuses  on  improving  the  interaction 
between  computer-based  system  and  the  users  or  developers 
of  software.  In  her  article,  [Ret.  19 j  Elizabeth  Kruesi 
lists  three  basic  objectives  in  this  area? 


experience  base  through  the  application  of 
this  technology  to  actual  developmenf  project I;  and 

—  to  ensure  effective  human  factor  enoineerina  of  automated 


Although  Kruesi  suggests  many  technigues  and  methods 
for  improving  bool  usability  (such  as  dsfining  user  inter¬ 
face  gods,  early  user  testing,  predictive  tools  for  inter¬ 
face  design,  and  following  proven  interface-design 
guidelines),  she  sees  imperical  testing  as  the  one  human 
engineering  method  offering  the  most  promise.  Although 
noticeably  lacking  in  the  past  development  of  tools  and 
environments  for  software  personnel,  imperical  testing  is 
viewed  by  Kruesi  as  an  especially  "rich  source  of  ideas  for 
user  interfaces,  particularly  in  the  design  of  advanced 
software  environments  such  as  Smalltalk  and  Interlisp...." 

Although  one  of  the  benefits  that  will  be  realized 
from  the  improvement  cf  tool  usability  is  increased  produc¬ 
tivity,  the  primary  benefit  may  very  well  be  in  the  avoid¬ 
ance  of  human  error  in  the  design,  development,  and 
maintenance  of  life-dependent  and  mission-critical  DoD 
systems. 
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I.  CCSCIOSIOH 

This  chapter  has  presented  many  of  the  managerial  and 
technologically-oriented  objectives  that  DoD  has  incorpo¬ 
rated  under  the  STABS  program.  This  software  incentive  is 
enormously  broad  in  its  scope,  including  all  major  sectors 
of  society  in  both  present  and  future  efforts  to  keep  this 
country  at  the  forefront  of  software  technology.  Although 
still  in  its  infancy,  STABS  has  defined  many  existing  soft¬ 
ware  problems  and  has  established  both  evolutionary  and 
revolutionary  strategies  to  minimize  these  problems  in  the 
future.  The  conceptual  foundation  of  STABS  is  sound  and 
promises  to  improve  future  software  development  should  the 
program  receive  the  financial  support  that  it  deserves. 

STABS  is  an  aggressive  approach  to  a  well  defined  set  of 
problems.  The  key  to  the  success  of  STABS,  as  is  true  of  any 
government  initiative,  is  the  widespread  acceptance  of  the 
concepts  surrounding  it.  The  key  element  driving  STABS  is 
that  of  standardization  as  supported  through  commonalty  of 
methodology,  uniform  metrics  and  baselines.  The  software 
institute  calls  for  a  sharing  of  information  and  the  ever- 
increasing  technology  transfer. 
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The  gains  made  in  software  engineering  over  the  past  two 
decades  have  .been  significant,  yet  software  projects  fail¬ 
ures  continue  with  alarming  regularity  as  both  the  size  and 
complexity  of  computer-based  systems  continue  to  grow. 

There  is  no  shortage  of  proposals  to  confront  the  prob¬ 
lems  that  plague  the  development  and  acquisition  of  soft¬ 
ware.  Yet,  the  very  nature  of  software  continues  to  defy  its 
quantitative  analysis  resulting  in  obscured  visibility  and 
ineffective  controls  in  the  development  and  maintenance 
process. 

Although  great  strides  have  taken  place  in  the  fcraaula- 
tion  of  software  metrics  as  management  information  tools  and 
as  a  medium  to  provide  feedback  to  software  engineers, 
attempts  to  devise  metrics  to  guantify  software  quality  have 
remained  elusive.  Software  quality  assurance  programs,  such 
as  described  in  MI1-STD-52779  (A) ,  provide  a  planned  and 
systematic  approach  for  building  quality  into  software. 
Successful  implementation  of  these  programs  have  given 
credence  to  the  saying  the  "quality  is  free,"  in  the  long 
run  primarily  through  cost  savings  inherent  in  truely  main¬ 
tainable  software. 

Software  maintenance  is  the  neglected  phase  in  the  soft¬ 
ware  life-cycle.  Maintenance  accounts  for  well-over  half  of 
all  resources  expended  on  software  throughout  its  life.  The 
trend  in  the  amount  of  efforts  needed  to  maintain  software 
is  increasing  at  a  dramatic  rates,  consuming  resources  that 
were  once  reserved  for  developmental  efforts.  Yet,  project 
management  does  not  often  give  sufficient  consideration  to 
building  maintainability  into  software  as  an  indispensible 
criteria  in  the  design  process.  Various  technical  and 
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managerial  approaches  can  be  implemented  within  the  mainte¬ 
nance  activity  with  minimum  upheaval,  but  the  most  influen¬ 
tial  factors  leading  to  the  maintainability  of  software 
occur  during  the  phases  prior  to  the- maintenace  phase. 

Chapter  71  focuses  on  various  high-level  efforts 
directed  at  the  standardization  of  computer  technology  and 
software  within  DoD.  If  the  appropriate  selection  of  tools, 
methods,  and  methodologies  advocated  by  current  software 
literature  and  directives  were  to  be  put  into  practice, 
better  software  would  be  realized  in  DoD.  In  order  to 
assure  the  success  of  this  undertaking,  it  has  been 
suggested  by  numerous  authors  that  the  project  manager 
should  be  provided  with  sufficient  technical  background. 
This  approach  is  the  likeliest  to  assure  failure.  Today,  the 
framework  in  which  DoD  software  is  acguired  and  developed  is 
both  disjointed  and  perplexing.  The  myriad  of  instructions 
and  guidelines  offer  platform  of  confusion  not  resolution. 
Significant  progress  has  been  made  by  groups  such  as  the  JCL 
in  attempting  to  standardize,  through  joint-service  instruc¬ 
tions,  many  of  the  aspects  affecting  the  acguisition  and 
maintenance  of  software.  Much  remains  to  be  done. 

The  immaturity  of  the  software  engineering  discipline 
has  been  too  often  been  pointed  to  as  the  primary  culprit  of 
software  failure.  Software  engineering  must  never  mature;  it 
must  continue  to  evolve  at  a  pace  set  by  advances  in  our 
technological  society.  Software  engineering  is  but  one  of 
the  factors  contributing  to  the  delivery  of  quality  soft¬ 
ware.  Standardization  is  the  key  in  reversing  the  trend  of 
the  delivery  of  overbudget,  overschedule,  inferior  software. 

The  management  and  development  of  software  today  is  like 
trying  to  understand  a  United  Nations  assembly  without 
interpreters.  Today  there  are  far  more  programming 
languages  than  there  are  different  languages  at  the  United 
Nations,  with  revisions  bastardizing  the  integrity  of  its 


parent  programming  language  as  dialects  bastardize  their 
mother  language.  Yet  programming  languages  is  just  one 
aspect  of  the  total  standardization  effort  that  must  taXe 
place  in  DoD.  The  best  of  today's  management  systems  can  be 
consolidated  into  a  single,  joint-service  system  understood 
by  management  personnel  in  both  DoD  and  industry.  The  adop¬ 
tion  of  any  one  set  of  tools,  methods,  and  methodologies  for 
the  development  and  acquisition  of  software  is  far  better 
than  attempting  to  live  by  all  of  the  sets  available. 

Benefits  derived  through  standardization  snould  be 
exploited  to  their  fullest.  The  broadest  and  most  farsighted 
of  these  efforts  is  the  STABS  program,  which  addresses  most 
aspects  that  define  the  total  software  life-cycle 
environment. 
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APP3MDII  & 

GLOSSARY  OF  SOFTWARE  QUALITY  ATTRIBUTES 


Definitions  provided  in  this  appendix  are  derived  from 
[Ref.  18  :  Appendix  B ]  and  [Ref.  16  :  pp.  3-4  -  3-24]. 


ACCESSIBILITY:  Code  possesses  the  attribute  accessi¬ 
bility  to  the  degree  that  it  facilitates  selective  use  of 
its  parts. 

. ..  ACCOUNTABILITY:  Code  possesses  the  attribute  accounta- 
billlty  to  the  degree  that  it  degree  that  its  usage  can  be 
measured. 

ACCURACY:  Code  possesses  the  attribute  accuracy  to  the 
degree  that  its  outputs  are  sufficiently  precise  to  satisfy 
their  intended  use. 


.  AUGMENTABILITY:  Code  possesses  the 
ability  to  the  degree  that  it  can  easil 
sion  in  component  computational  functi 


_  _  componen 

requirements. 


ossesses  tl 

_  '  can  easily  accommodate  Sxpan- 

mputational  functions  of  data  storage 


attribute  augment- 
id* 


COMMTJNICATIVENE 
cativeness  to  the  d 
tion  of  inputs  and 
are  easy  to  assimll 


SS:  Code  possesses. the  attribute  cosmuni- 
that  It  facilitates  the  specifica- 


egree  that  it  facilitate 
provides  outputs  whose 
ate. 


e  spec 
:orm  an<! 


§*  content 


COMPLETENESS:  Cade  possesses  the  attribute  completeness 
to  the  degree  that  its  parts  are  present  and  each  part  is 
fully  developed. 

This  implies  that  external  references  are  available  and 
required  functions  are  coded  and  present  as  designed. 


SCNCISENESS:  Code  possesses  the  attribute  conciseness  to 
egree  that  excessive  information  is  not  present. 


JCNSISTENCY:  Code  possesses  the  attribute  consistency  to 
the  degree  that.it.  contains  uniform  notation,  terminology, 

tnd  symbology,  witain  itseif,  and  external  consistency  to  the 
egree  that  the  content  Is  traceable  to  the  requirement. 


,  DEVISE  EFFICIENCY:  Code  possesses  this  attribute  to  the 
degree  that  it  that  the  operation,  function,  or  Instructions 

Provided  by  the  code  are  performed  without  waste  of 
esources  with  respect  to  that  device. 

DEVICE- INDEPENDENCE;  Code  possesses  this  attribute  to 
the^.  degree  that  it  can  be  executed  on  computer  hardware 
configurations  other  than  the  current  one. 

.  . efficiency s  Code  possesses  this  attribute  to  the  degree 
that  it  fulfills  its  purpose  without  waste  of  resources. 


de 

us 


HUMAN  ENGINEERING:  Code 
gree  that  It  fulfills  i 
er*s  time  and  energy,  or  d 


possesses  this  attribute  to  the 
ts  purpose  without,  wating  the 
egraaing  their  morale. 
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LEGIBILITY 
that  it  Is  eas 


to  the  degree 


„  MAINTAINABILITY;  Code  possesses^ this 
degree  that  it  facilitates  updating  to  sa 
meats  or  to  correct  deficiencies. 


attribute  to,  the 
tisfy  new  reguire- 


MCDIFIABILITY:  Code  p 
degree  that  It  facilitate 
once  the  nature  of  the  desi 


ossesses  this 
s  the.  incor 
red  change 


his  attribute  to 
rporation  of  chang 
has  been  determined 


the 

es. 


PORTABILITY :  Code  possesses  this  attribute  to  the  degree 
that  It  can  be  operated  easily  ana  well  on  computer  configu¬ 
rations  ether  than  its  current  one. 


RELIABILITY;  Code  possesses  this  attribute  to  the  degree 
that  It  can  fie  expected  to  perform  its  Intended  functions 
satisfactory. 


ROBUSTNESS;  Code  possesses  this  attribute 
that  it  can  continue  to  perform  despite  some 
the  assumptions  m  its  specifications. 


to  t 
vio 


SEIF-CCNTAIMEDNESS:  Code  possesses  this 
degree  that  it  performs  all  its  explicit  an 
tions  within  itself. 


the 

unc- 


S ELF-DESCRIPTIVE NESS :  Code  possesses  this  attribute  to 
the  degree  that  it  contains  enough,  information  for  a  reader 
to  determine  and  verify  Its  objectives,  assumptions, 
constraints,  inputs,  outputs,  components,  and  revision 
status. 


STRUCTUREDNESS:  Code  possesses  this  attribute  to  the 
degree  that  It  contains  a  definite  pattern  of  organization 
of  its  interdependent  parts. 

TESTABILITY:  Code  possesses  this  attribute  to  the  degree 
that  it  facilitates  the  establishment  of  verification 
criteria  and  supports  evaluation  of  its  performance. 

UNDER STAND ABILITY:  Code , possesses  this  attribute  to  the 
degree  that  Its  purpose  is  clear  to  its  inspector. 

USABILITY:  Code  possesses  this  attribute  to  the  degree 
that  it  is  reliable,  efficient,  and  human-engineered. 
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HALSTEAD  AID  MCCABE’S  SOFTHAEE  METRICS 


As  generally  addressed  in  Chapter  III,  this  appendix 
will  present  guanti fiaJble  measurements  of  various  software 
charateristics  using  hoth  Halstead’s  Software  Science  Theory 
and  McCahe’s  Complexity  Measure. 

A.  HALSTEAD’S  SOFTWARE  SCIEHCE 

Halstead  begins  with  four  basic  metrics: 

1.  nl — the  number  of  unigue  or  distict  operators  cn 
the  program. 

2.  n2 — the  number  of  unigue  or  distinct  operands  in 
the  program. 

3.  Nl— the  total  usage  of  all  the  operators  in  the 
program. 

4.  N2 — the  total  usage  of  all  the  operands  in  the 
program. 

Tables  7  and  8  show  the  resulting  counts  of  the  operators 
and  operands  used  the  algorithm  used  in  table  6  .  [Ref.  10 
:  pp.  3  -  IP] 


The  2££3&JLlS£Z  (n)  of  a  module  is  described  as  the  sum 
of  its  unigue  operators  and  operands: 


TABLE  C 

A  Sorting  Subroutine 

SUBROUTINE  SORT  (S,N) 
DIHENSION  XfN)  ' 

IF  iN  .LT.  V  RETORN 
DO  20  I  «  2,N 

DO  10  J  ■  1,1 
IF  (X(I)  .gL 
SAVE  » 


CONTINUE 

CONTINUE 

RETURN 

END 


mi 


GO  TO  10 


TABLE  7 

Operator  Count 

Operators 

Coui 

End  of  statement 

Array  subscript 

h  « 

DO 

7 

find  of  program 

•  L  T  • 

*  8E. 

GO  TO 

? 

i 

] 

10 

N1  -  28 

TABLE  8 
Operand  Count 


Operands 


1  e 

A 

I 

J 

4. 

N 

5. 

2 

6. 

SAVE 

7. 

1 

n2  »  7 


N  2 


Count 

6 

5 

4 

2 


1 

22 


Halstead  also  introduced  a  formula  for  the  estj n&t^et 

Isiisih  (M) : 

NH  *  n11og2n1  +  n21og2n2 

The  estimated  length  eguation  (NH)  has  proven  an  accep¬ 
table  estimator  for  the  length,  N,  of  a  module.  The  useful¬ 
ness  of  NH  seems  to  be  somewhat  sensitive  to  actual  program 
length.  Test  have  shown  that  this  formula  works  best  for 
programs  if  N  is  in  the  range  between  2000  and  4000.  In  this 
light,  errors  can  minimized  by  breaking  down  modules  to 
where  they  are  within  these  parameters  [Ref.  11].  Halstead 
attributes  this  finding  to  the  presence  of  "impurities'’  in 
the  program  reguiring  optimization. 

When  compared  against  the  actual  length  of  the  above 
listed  algorithm  one  finds  that  N  *  50  and  NH  *  52.9,  a 
difference  of  less  than  5.8%  in  this  particular  case. 

Additional  metrics  were  defined  by  Halstead  using  the 
terms  already  presented.  Of  interest  is  another  measure  of 
program  size  called  volume.  (V),  which  is  measured  in  bits; 

V  »  N  x  log2n 
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Volume  may  also  be  interpreted  as  the  number  of  mental 
comparisons  needed  tc  write  a  program  of  length  N,  assuming 
a  binary  search  method  is  used  to  select  a  member  of  the 
vocabulary  size  u.  The  most  succint  form  in  which  an  algo¬ 
rithm  can  be  expressed  requires  prior  existence  of  a 
language  in  which  the  required  operation  has  already  been 
defined  cr  implemented*  In  such  a  case,  the  implementation 
of  that  algorithm  would  require  no  more  than  naming  of  oper¬ 
ands  for  its  arguments  and  its  resultants  (eg.  SORT(X)). 
These  algorithms  are  considered  minimal  in  size  and  are  said 
to  have  the  £fi£gjiiai  volume  £*: 

V*  *  (2  ♦  n2)  x  log2  (2  +  n2*) 

(where  n2*  is  the  different  input  and  ouput  parameters) 

Any  program  with  volume  V  is  considered  to  be  implemented  at 
the  pisgjcaJS  lgysl,  L,  defined  as: 

h  V*/V 

Notice  that  for  the  most  succint  version  of  any  algorithm, 
the  resultant  is  1.  As  the  unig-ue  operators  (nl)  increase 
and  the  reuse  of  operands  (N2)  increases  ths  resultant 
approaches  0.  The  term  "difficulty"  is  derived  from  the 
logic  that  as  the  volume  of  a  program  increases,  the  program 
level  (L)  decreases  and  the  difficulty  increases.  Thus, 
iiyjL£ASjiiiZ  (D)  is  the  inverse  of  the  program  level 

D  *  1/L 

Since  the  volume  (V)  is  the  number  of  mental  compari¬ 
sons,  and  the  difficulty  (D)  is  the  measure  of  the  average 
elementary  mental  discrimination  required  for  each  mental 
comparison,  then  by  combining  the  formulas  for  L  and  D,  the 
total  number  of  elementary  mental  discriminations,  ef forfr. 
(E) ,  reguired  to  generate  a  program  can  be  derived  from 

E  ■  V/L 
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The  advantage  of  Holstead's  measurement  of  effort  (£)  is 
a  significant  break  from  traditional  use  of  LOC*s.  The  use 
of  lCC's  required  the  collection  of  data  and  regression 
analysis.  Only  the  number  and  use  of  operators  and  operands 
are  needed  to  derive  measurements  for  effort,  thus  over¬ 
coming  the  forementioned  difficulties  of  using  LOC*s  method¬ 
ology.  Another  advantage  of  using  E  is  that  it  is  a  strong 
indicator  of  the  ccmprehensiblity  of  a  program  and  its 
propensity  for  errors  [Ref.  10  :  p.  16]  and  [Ref.  11  :  p. 
34]. 

Exploring  the  formula  for  L  further,  it  can  be  noted 
that  as  the  potential  volume  (V*)  increases,  the  program 
level  (1)  decreases  proportionately.  Consequently,  the 
product  1  times  7*  remains  constant  for  any  one  language. 
This  product,  the  language  j,evel.  which  is  denoted  as 
LAMBDA,  is  derived  by  the  following  formula 

LAMBDA  »  L  x  7* 

The  last  of  Holstead's  formulas  to  be  discussed  is  used 
to  measure  the  programming  tia$  (TH)  for  a  program  in 
seconds.  Halstead  adopted  the  concept  introduced  by  John 
Stroud,  a  psychologist,  who  defined  a  "moment"  as  the  time 
required  by  a  human  brain  to  perform  the  most  elementary 
discrimination.  These  "moments"  according  to  Stroud,  occur 
at  a  rate  of  5  to  slightly  less  than  20  per  second. 
Halstead  then  determined  that  the  programming  time  of  a 
program  could  mathematically  be  defined  as 

TH  ■  E/S 

(where  S  »  the  "Stroud"  number  »  18) 

Halstead  reason  for  selecting  "18"  for  the  value  of  the 
Stroud  number  remains  a  mystery,  but  it  fits  his  formula 
nicely  and  is  likely  to  remained  unchallenged  until  the 
disciplines  of  cognitive  psychology  and  software  science 
merge. 
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B.  HCCABES’S  COflPLEXiTY  MEAS08E 

A  program  graph  is  used  to  represent  control  flow,  as 


figure  B. 1  Control  Flow  Graph  Complexity 

illustrated  in  Figure  B. 1  [Ref.  12  :  PP.  308  -320]  The 

circles  represent  processing  tasks,  which  can  be  one  or  more 
source  code  statements.  Arrows  depict  control  flow 
(branching)  between  processes.  Thus,  in  Figure  B.1  ,  process 
"a”  may  be  followed  ty  process  "b, "  "c,"  or  "d,"  depending 
on  which  condition  was  satisfied  in  process  "a."  The  control 
flows  depicted  by  arrows  going  from  process  "e"  to  processes 
"b"  and  "c"  represent  "backward"  branching.  "Regions"  may  be 
described  as  the  enclosed  areas  on  the  plain  of  the  graph 
represented  by  R1  through  R5  in  Figure  MCCABE  FIG.  These 

V 

regions  represent  the  bounded  areas  within  the  program 
graph,  as  well  as  the  unbounded  area  outside  of  the  graph. 
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McCabe  uses  a  software  complexity  measure  that  is  based 
on  what  he  terms  the  "cyclomatic  complexity"  of  a  program 
graph  for  a  module.  One  approach  that  can  be  applied  in 
determining  the  cyclomatic  complexity,  V  (G) ,  is  by  calcu¬ 
lating  the  numbers  of  regions  in  a  planar  graph.  In  Figure 
B.  1  ,  for  instance,  V(G)  is  egual  to  5.  Another  method  is 
through  the  formula 

?(G)  »  e  -  n  ♦  2p 

in  which  "e"  is  egual  to  the  number  of  "edges,"  i.e.  number 
of  arrows,  "n"  is  egual  to  the  number  of  "vertices,"  or 
processes,  and  "p"  is  egual  to  the  number  of  connected 
components.  In  Figure  B.1  ,  the  values  of  these  elements 
are: 

n  *  6  (a,  b,  c,  d,  e,  f) 

e  *=  9  (a  to  b,  a  to  c,  a  to  d,  b  to  e,  e  to 
b,  e  to  a,  d  to  c,  e  to  f,  c  to  f) 

p«1 

By  inserting  these  values  into  the  above  formula,  the 
resulting  cyclomatic  complexity  metric,  V (G)  is  again  egual 
five.  McCabe  also  contends  that  the  7(G)  measure  can  provide 
a  guantitative  indication  of  the  maximum  size,  testing 
difficulty,  and  reliabilty  of  a  module.  Through  empirical 
investigation,  he  has  found  that  a  cyclomatic  complexity 
measurement  of  10  to  be  a  practical  upper  limit  for  module 
size.  Exceeding  this  upper  limit  makes  it  increasingly 
difficult  to  adeguately  test  a  module. 
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STRUCTURED  METHODOLOGIES 


A s  discussed  in  Chapter  V,  the  design  of  maintainable 
software  is  based  on  the  application  of  a  set  of  engineering 
principles  and  practices  that  include: 

—  Structured  analysis 

—  Structured  design 

—  Structured  programming 

—  Program  design  language 

This  appendix  presents  the  detailed  characteristics  cf  these 
elements  as  provided  in  [Ref.  26  :  Appendix  A]. 


A.  STRUCTURED  AHAIYSIS 

When  applied  to  software  development,  the  characteris¬ 
tics  of  structured  analysis  and  the  logical  model  are  as 
follows: 

—  A  system  is  described  by  the  systematic  decomposition  ’ 
of  broad  system  functions  into  subunctions  of 
progressively  finer  detail. 

—  Each  function  and  subfunction  is  defined  by 
describing 

Its  inputs  and  outputs 

Processing  activities  and  requirements 

Nontransient  data  stored  by  the  function 

—  Functions  and  subfunctions  are  analyzed  to  access 

The  support  of  functions  by  hardware  and  software 

Algorithm  and  computational  requirements 
(Function,  precision,  range,  timing,  etc.) 

The  need  fcr  performance  and  tradeoff  studies 

—  Stored  and  interface  data  are  analyzed  to  access 

Access  requirements 

Structured,  format,  and  storage  requirements. 


—  Functions  and  data  are  analyzed  to  evaluate  the 
requirements  for  execution  and  support  software. 

The  net  result  of  the  this  structured  analysis  process 
should  be  a  logical  model  that  defines  the  complete  system 
which  reflects  all  facets  of  the  system  specification  and 
software  requirement  document.  The  model  should  be  a  form  of 
communication  easily  understood  by  both  technical  and 
nontechnical  personnel,  alike.  Through  the  use  of  this 
model,  the  system  analyst  should  be  to  develop  system 
requirements  without  undue  consideration  of  physical  imple¬ 
mentation  constraints.  On  the  other  hand,  nontechnical  users 
should  readily  be  able  understand  how  the  required  functions 
fit  together  within  the  context  of  the  whole  system. 


B.  STRUCTURED  DESIGH 


Structured  design  is  the  process  of  subdividing  the 
software  design  into  hierarchical  in  a  manner  that  tends  to 
maximize  module  independence.  Benefits  provided  to  the 
development  and  maintenance  include  increased  understan- 
dility  of  the  system  and  a  minimization  of  the  expenses 
associated  alteration  of  the  software. 

The  structured  design  approach  has  the  following  charac¬ 
teristics: 


fi 


Hierarchical  functional  tree  charts  are  developed 
shoein  a  serie?  of  boxes  representing  descending 
levels  of  functions  and  subfunctions.  These  charts 
epict  the  functionality  in  the  same  sense  that  a 
-oject  work  breakdown  structure  (WBS)  depicts 
erarchies  of  work  to  be  performed  by  a  contractor. 

Modularity  of  components  is  emphasized,  A  key  charac¬ 
teristic  of  modularity  is  a  maximum  independence  of 
one  component  from  others.  This  independence  allows 
for  a  concentration  on  definition  of  inputs,  outputs 
and  processing  of  each  component.  It  also  facili- 
tates  design  clarity,  which  facilitates  future  modi- 
iic dtions • 


—  At  each  level. of  comp 
placed  on  defining  In 
each  component.  T 
characteristic  of 
analysis. 


onent  design,  strong  emphasis  is 
puts,  outputs,  and  processing  of 
his  emphasis  represents  a  key 
both  structured  design  and 
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C.  STBOCTURED  PROGRAMMING 

Structured  prograsming  requires  that  a  programmer  use 

only  a  limited  set  of  three  basic  program  structures. 

These  are  depicted  in  Figure  4.3,  and  are  as  follows: 

—  Sequence  of  two  or  more  operations 

—  Conditional  branch  to  one  of  two  operations  and 
return  (XF  a  then  b  else  c) 

—  Repetition  of  an  operation  (DO  WHILE) 

Any  program,  regardless  of  its  complexity,  can  be  imple¬ 
mented  using  these  basic  program  structures.  The  use  of  only 
these  structures  limit  the  procedural  design  of  a  program  to 
a  small  amount  of  predictable  operations.  It  should  be 
noted,  however,  that  use  of  only  these  three  structure  may 
lead  to  inefficiencies  in  situations  such  as  when  an  escape 
from  a  set  of  nested  conditions  or  loops  is  needed.  In  situ¬ 
ations  such  as  these,  the  designer  if  left  with  the  options 
of  re-design  to  avoid  these  conditions  or  allow  for  devia¬ 
tion  from  these  basic  structures  in  a  controlled  manner. 

Two  extensions  to  the  basic  structures,  also  illustrated 
in  Figure  4.2,  are  the  DO  UNTIL  and  CASE  structures.  These 
are  special  cases  of  the  other  structure  which  improve  both 
redability  and  source  code  without  degrading  programming 
structure. 

D.  PROGRAM  DESIGN  LANGUAGE 

A  program  design  language  is  a  basically  a  test 
processor  that  is  used  to  document  a  structured  design.  It 
has  the  following  two  characteristics: 

—  It  produces  an  English-like  representation  of  compo¬ 
nents  of  code  that  are  easy  to  read  and  comprehend. 

—  It  is  structured  in  the  sense  that  it  uses  structured 
programming  constructs  to  show  nested  logic. 
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